<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-7098741402030378580</id><updated>2012-01-22T23:49:01.848-05:00</updated><category term='motivation'/><category term='Understanding GFW'/><category term='Social Engineering'/><category term='parody'/><category term='GFW-metrics'/><category term='off-topic'/><category term='about'/><category term='DIY'/><title type='text'>GFW技术评论</title><subtitle type='html'>I thought what I'd do was, I'd pretend I was one of those deaf-mutes, or should I?</subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>13</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-707341345779874315</id><published>2010-03-21T07:48:00.000-04:00</published><updated>2010-03-21T07:48:27.863-04:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='about'/><category scheme='http://www.blogger.com/atom/ns#' term='Understanding GFW'/><title type='text'>深入理解GFW：结论</title><content type='html'>&lt;p&gt;作为深入理解系列最后一篇，有好几个平行的话题在这里一并讨论了。&lt;/p&gt;

&lt;h3&gt;西厢的弱点和局限&lt;/h3&gt;

&lt;p&gt;首先泼一盆冷水。&lt;/p&gt;

&lt;p&gt;西厢远没有你们想象得那样强大，它有很多弱点和局限：&lt;/p&gt;
&lt;ul&gt;
 &lt;li&gt;对IP封锁无效。比如加载之后也不能访问twitter.com。&lt;/li&gt;
 &lt;li&gt;对无状态的TCP阻断无效。比如有一段时间的docs.google.com:443。&lt;/li&gt;
 &lt;li&gt;不稳定。不少用户反应使用时有时候仍然会连接被重置。&lt;/li&gt;
 &lt;li&gt;受环境影响大。因为要求网络中间节点都遵守RFC，不少NAT内网用户无法使用，装了防火墙也可能造成无法使用，在虚拟机内开启也可能无法使用。&lt;/li&gt;
 &lt;li&gt;安全性没有改善。用户的通信仍然是原样，明文仍然是明文，被动监听设备依然正常截获用户的通信。&lt;/li&gt;
 &lt;li&gt;受制于GFW的变动。GFW指纹逻辑比较复杂，只能通过硬编码来描述。如果GFW更新工作方式细节，那么匹配模块就需要重写更新才能使用。&lt;/li&gt;
 &lt;li&gt;另外，有ipv6线路的用户访问Youtube不需要使用西厢。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;而它的优点是，免费，无中转性能开销。因此，到发布为止，只想到Youtube最大地展示了它的优点而较少受到缺点影响。而产生幻觉，只看到优点看不到缺点是多数人会犯的错误。&lt;/p&gt;

&lt;a name='more'&gt;&lt;/a&gt;

&lt;h3&gt;西厢是什么不是什么&lt;/h3&gt;

&lt;p&gt;西厢提出的是一种技术而不是一种资源，因此没有西厢客户端一说，也不存在被封。西厢所做的只是指出了墙上本来存在的裂缝，而且这个裂缝是可以利用的。&lt;/p&gt;

&lt;p&gt;之前我们说过：其他一些低成本但有一些缺点的方法也暂时作为折中而继续存在研究价值。私有SSH代理和私有VPN才是当前状况下的最优解决方案，但是由于这两种方法有较高的成本。西厢不会也不能替代私有SSH代理和私有VPN在翻墙中起到的作用。西厢不是对GFW的银弹。GFW是一个复杂的系统，不存在对它的银弹。&lt;/p&gt;

&lt;p&gt;0.0.1版的发布是面向开发者的，完全没有考虑用户体验。原开发组没有任何继续开发的计划，没有任何移植的计划。任何继续的开发和移植是所有后来人的功劳。&lt;/p&gt;

&lt;p&gt;西厢的开发有多难？有人拿毕设来与之相比，这有点不可思议。事实上，西厢的原理部分一年前就完成了，主要依据就是T. Ptacek的那篇论文，实验结果也很好。而最终的netfilter实现者说他花了一周时间看内核代码netfilter那部分，然后就着现成的代码直接改成现在这个样子了。难吗？为什么西厢压了一年没有发出来？在这一年中，&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;这样一些系列从零到有的文章，是要展示一种对GFW进行全面理解的学习过程和方法，表达一种对GFW进行逆向工程的趣味。读者不应该仅仅作为一个信息的接收者，而是应该有自己积极的思考。如果读者中有百分之一开始自己思考关于GFW的问题，千分之一开始自己动手研究GFW，如果有万分之一开始将原理付诸实践，那就是很好的结果。如果所有人都只是伸手而没有动力去自行了解GFW，那么就只会让GFW越来越强大，而自己被动挨打被GFW追得到处跑。GFW在背后技术力量的推动下变动不居，不断地被更新、不断地发生变化，对GFW永远正确的认知或者一劳永逸的翻墙方法并不存在，只有与之对抗的方法和学习动力能留存下来。……&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;西厢的提出就是为了说明，GFW也远没有你们想象得那样强大，而是充满了漏洞。只要你敢于动手，就一定有所收获。请记住，&lt;cite&gt;西厢是个tech demo&lt;/cite&gt;，发布出来不是给你用的，而是给你研究的。如果你认为你的能力不比哈工大、北邮那些筑墙的学生差，那么请你体现你的存在。&lt;/p&gt;

&lt;h3&gt;GFW如何应对西厢的挑战&lt;/h3&gt;

&lt;p&gt;不说非常困难，解决西厢揭示的漏洞也不是一件简单的事情。&lt;/p&gt;

&lt;p&gt;首先，GFW的规模极为庞大，这给打补丁的难度带来了本质的变化。如果是一个一般小型网络出入口上部署一台主机做的IDS，给TCP栈打补丁还相对容易。而在分布式和并行计算的体系结构下，在几千个计算节点的规模上做任何事情都不容易。&lt;/p&gt;

&lt;p&gt;其次，GFW的设计思想从一开始就没有重视完备性。以前已经讨论过了，GFW很多模块的设计给人这样的感觉：得过且过，刚好可以工作。而且这些问题实际上很久都不修复。比如这次西厢展示的这个漏洞，其原因来自GFW的多线程TCP栈还原全连接时，将通信分成两个half_stream处理，从而避免数据共享控制造成的锁开销的做法。往好的方向看，这可以在性能上带来提升，以完备性的损失换来计算的简化也是一种实用主义哲学。往坏的方向看，这就打开了漏洞的大门。这也就意味着，GFW面临这种的情况：修补漏洞，性能大幅下降；完善TCP栈，性能急剧下降。&lt;/p&gt;

&lt;p&gt;然后，GFW完全修复漏洞的难度很大。按照&lt;cite&gt;Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection&lt;/cite&gt;一文的结论，如果NIDS的TCP栈与两端的TCP栈有不一致，就会存在可以用的漏洞。何况GFW这种简陋的TCP栈，可以说漏洞百出。我们曾经枚举过，有一百多种报文的字段组合可以实现当前这种效果。如果GFW不完全重写其TCP栈以符合RFC，那么像西厢展示的这么简单易用的漏洞还会有不少。即使GFW实现了RFC完备的TCP栈，《入侵防御系统的评测和问题》还论证了基于TTL的注入是理论上不可避免的。&lt;/p&gt;

&lt;p&gt;最后，GFW的研发运维实力很成问题。首先已知，有不少学生在参与GFW的研发，而GFW的模块质量参差不齐正反映出其研发能力不足的状况。GFW的质量控制也应该是很有问题的，2007年7月17日GFW造成的全国性邮件事故处理之缓慢，让人对GFW的运维能力产生很大的疑问。&lt;/p&gt;

&lt;p&gt;总之，&lt;cite&gt;GFW的屁股比微软还大，懒得挪&lt;/cite&gt;。&lt;/p&gt;

&lt;h3&gt;对GFW进行DDoS&lt;/h3&gt;

&lt;p&gt;我们一直不提这件事情。DDoS有很多问题。&lt;/p&gt;

&lt;p&gt;首先，DDoS是一个脏活。DDoS首先需要组织botnet，这种事情跟贩卖人口差不多，低级。&lt;/p&gt;

&lt;p&gt;其次，DDoS在任何国家都是非法的。2009年5月19日民用DNS攻击案，四个脚本小子荣获“破坏计算机信息系统”奖章。GFW可是号称国家信息海关、国家信息安全基础设施，攻击它，万一被抓了人命事儿小，你的开源项目没有人继续帮你做，多郁闷啊。&lt;/p&gt;

&lt;p&gt;再次，DDoS在战略上只会产生负面结果。在这个拔网线司空见惯的时代，推倒GFW，不但不会改善互联网审查的状况，反而可能造成实名制和金盾的崛起——一帮只会整人不懂技术的胡乱拔网线、军管互联网。《总论》就已经说过，双方需要的是一种斗争状况下的动态平衡。大家都得过且过，退避三舍，网民翻墙有方，GFW对上面有交代，就行了。最多偶尔之偶尔，逢年过节，比如国庆或者春节的时候，DDoS开个口子让大家出去遛一遛。&lt;/p&gt;

&lt;p&gt;当然，虽说问题多多，DDoS的可行性还是有的，GFW的计算规模总归还是有限的。2010年1月3日前后的“解封”据说就跟GFW北京被DDoS有关系。不过也不会详细讨论其方法，只是小字提一下……&lt;small&gt;组织DDoS，先要对全国的网络拓扑很清楚，这就涉及网络测量的课题；也要对GFW的结构了解得很透彻，弱点在哪里，负载均衡算法是怎样的；怎样做最有效，是点射还是温水煮青蛙；怎样反反DDoS，怎样空对空射击。这些都需要学习。其次，DDoS的效果需要一套精细的评估体系，如果不成功需要快速改变策略。GFW不是常规的服务器，成功与否并不是那么显著。因此需要建立一个监测网，在全国不同的ISP对GFW的多种指标实施实时观测。比如不同协议下的阻断响应延迟，TCP的SYN超时和ACK超时时间，各个DNS服务器污染的情况，窗口值的增速等等。所以说这个事情要做也不简单。顺便一提，这个监测网所用监测工具，我们最初给它命名为Collaborative Network Measurement Toolkit for GFW，简写为CNMTG；当然了，这是一个自命名完成之后就停止开发的雾件。&lt;/small&gt;&lt;/p&gt;

&lt;h3&gt;结论的结论&lt;/h3&gt;

&lt;p&gt;对于普通用户来说，未来的翻墙方式中，我们最推荐私有SSH代理和私有VPN，在安全性和稳定性上有优势，组队合购VPS或独立主机建VPN更好。&lt;/p&gt;

&lt;p&gt;批评家们，请正确对待参与GFW建设的技术人员。技术是中性的，是无罪的，只不过技术为政治所利用。GFW的确在防控蠕虫病毒和垃圾邮件上有重要作用。至于方滨兴院士，他更像是一个营销人员或者政客而不是科学家。&lt;/p&gt;

&lt;p&gt;每个国家的老大哥都有一样的爱好，就是以国家安全的名义无限扩张权力。米帝用来做网络深度检测的CNCI，预算300亿刀，是GFW、金盾的多少倍？没有那个局的全球阴魂你感觉到了吗？唯一的区别在于，我朝的老大哥做事情太笨拙没下限让普通人也能看出破绽，而资本主义国家的自由民在恐怖中投靠老大哥的无限权力。赛博朋克的曙光还有很久才能看到，对抗前赛博朋克旧势力需要megacorp更快速地成长，所以Google你需要do evil的时候一定不要犹豫。&lt;/p&gt;

&lt;p&gt;工信部你好，我们建议：把网络封锁的过程规范化透明化，细化封锁规格和标准，制约滥用和不懂业务胡乱封锁，开放申诉渠道，允许网站自查自纠，一切依法进行。看在我们没有直接往贵部直属单位门面上喷漆的份上，这个建议还是有诚意的吧？&lt;/p&gt;

&lt;p&gt;Greetings fly out to tek4, KLZ毕业, iGFW, nust-, 店长, r007, r008, t00ls, em777, eviloctal, ZWA, Tor project, i2p, 会長.&lt;/p&gt;

&lt;p&gt;读者们，看到这里之时，我们已经解散了。祝大家……&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-707341345779874315?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/707341345779874315/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2010/03/gfw.html#comment-form' title='62 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/707341345779874315'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/707341345779874315'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2010/03/gfw.html' title='深入理解GFW：结论'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>62</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-25314481385791363</id><published>2010-03-21T07:31:00.000-04:00</published><updated>2010-03-21T07:31:04.582-04:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='DIY'/><title type='text'>HTTP URL/深度关键词检测</title><content type='html'>&lt;p&gt;一项持续时间比张某还长的遗留研究。下面是它的开发研究简介，细节很多，非研究者可以略去不看。&lt;/p&gt;
&lt;a name='more'&gt;&lt;/a&gt;
&lt;fieldset&gt;
&lt;legend&gt;&lt;strong&gt;HTTP URL/深度关键词检测&lt;/strong&gt;&lt;/legend&gt;
&lt;h4&gt;GFW的TCP协议阻断方式&lt;/h4&gt;
&lt;p&gt;GFW只根据单向的报文还原通信内容进行协议分析和关键词判断。并且在还原通信内容时，并不检查ack域的正确性，这也符合其“better is worse的设计哲学”，对于seq重叠的包，GFW的策略是忽略后来的包，因此利用GFW的这种流重组特性对其进行欺骗也十分容易。&lt;/p&gt;

&lt;p&gt;一旦GFW根据还原出的内容检测到关键词，会根据触发关键词的包和关键词类型发送type1的RST或者type2的RST/ACK，在《&lt;a href="http://www.chinagfw.org/2009/09/gfw_21.html"&gt;入侵防御系统的评测和问题&lt;/a&gt;》中已经介绍，type2类型首次阻断中会先发送一组三个RST/ACK，序列号依次加1460、2920。type1与type2有所不同的是，type1首次阻断发送的RST的seq是关键词结束位置所在的包的ack，type2的seq则可能取为在此之前若干个包的ack，这可能与GFW处理报文的buffer大小和更新方式有关。在有些地区，单向发送内容触发type2关键词之后本地无法收到RST/ACK（对方可以收到），除非对方回复过任何设置了ACK选项的tcp包，另一些地区则本地总可以收到RST/ACK，原因还不清楚。这些问题希望有兴趣的读者自行研究。&lt;/p&gt;

&lt;p&gt;特定情况下GFW还会伪造通信，例如type2的继发阻断中发送伪造的SYN/ACK企图劫持连接（为什么功能没有开发完全？），再如GFW的邮件检测模块对smtp协议的阻断会先伪造对方发送一条错误信息，再进行阻断。&lt;/p&gt;

&lt;h4&gt;URL关键词的检测&lt;/h4&gt;
&lt;p&gt;GFW的HTTP关键词检测模块的具体细节不是这里的重点，这里只回顾一些有关关键词检测的内容：&lt;/p&gt;
&lt;ul&gt;
 &lt;li&gt;GFW有两种不相关的type、GFW结点的划分与TCP包的源端口无关、GFW时常有结点不工作、type1不工作的节点和type2不工作的结点不同。&lt;/li&gt;
 &lt;li&gt;URL关键词同样也有type1、type2之分。&lt;/li&gt;
 &lt;li&gt;即使单向发送HTTP询问在一些地区可能无法收到GFW的type2 RST/ACK，实际上确实触发了关键词，会有90秒继发封锁。&lt;/li&gt;
 &lt;li&gt;如果询问的格式是GET http://url HTTP/1.1\r\n\r\n，GFW进行关键词测试串的就是url。&lt;/li&gt;
 &lt;li&gt;如果询问的格式是GET /url HTTP/1.1\r\nHost: hostname\r\n\r\n，GFW进行关键词测试的串就是.hostname/url。&lt;/li&gt;
 &lt;li&gt;GFW的HTTP URL关键词有普通的字符串关键词还有string1 &amp;&amp; string2 &amp;&amp; string3型的关键词，例如.google.com &amp;&amp; great &amp;&amp; firewall。只要url中包含这三个子串，无论出现的顺序如何，都会触发GFW。&lt;del&gt;令人疑惑的是，string1*string2这种关键词匹配（在url中string1、string2顺序出现）判断实现起来要比string1 &amp;&amp; string2容易得多，&lt;/del&gt;而目前已知的所有非普通关键词都是string1 &amp;&amp; string2形式而不是string1*string2形式，是否存在string1*string2形式的关键词需要知道更多的URL关键词。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;判断一个URL是否包含关键词的方法十分明了，选择一个跟本地IP分别在GFW两端的目标IP da，再任意选择一个不等于___的目标端口dp。对(da, dp)单向发送s;a;pa;s。（s = SYN; a = ACK; p = PSH）。为保证GFW按照顺序看到可以将每个包重复发送多遍，两组包间隔一定时间发送。如果触发了type1关键词可以收到GFW的r（RST），触发type2关键词可以收到GFW的sa。无sa或者无r，并不能说明不包含关键词，可能是GFW的相应结点不工作了。这时应该可以对此(da, dp)发送www.youtube.com来尝试触发。触发，说明原本确实没有关键词；否则说明GFW的相应类型的相应结点不工作了。&lt;/p&gt;

&lt;p&gt;对关键词进行手工求解未免太过低效，利用GFW的单向报文检测特性，可以用来进行关键词检测的(da, dp)是几乎无穷多而且便于寻找的，让程序自动检测关键词非常可行。&lt;/p&gt;
&lt;ul&gt;
 &lt;li&gt;情况1、假定只有一个关键词。&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;假设str长len，发起len个询问，第i个询问检测str去掉第i个字符形成的字符串。如果有阻断，说明这个字母可以去掉，否则说明这个字母不能去掉。询问完全并行。拿到所有结果之后可以立刻求出关键词。&lt;/li&gt;
  &lt;li&gt;理想情况下只要1单位时间。&lt;/li&gt;
 &lt;/ul&gt;
 &lt;li&gt;情况2、假定所有关键词都是普通关键词，求出所有最小关键词。&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;这种情况下可以进一步假定关键词是互不包含的子串，所以关键词可以定义前后关系。假设str长度为len，发起len个询问，第i个询问去掉前len + 1 - i个字符。求出最大的j使得在去掉前j个字符的情况下仍然有关键词。现在只需要求出从第j+1个字符开始的关键词，发起len - j个询问，第i个询问去掉后len - j + 1 - i个字符。现在求出最大的k使得去掉后k个字符仍然有关键词就完了。最后一个关键词就是str[j + 1..len - k]，共花去2单位时间、询问。接下来处理str[1..len - k - 1] with hint: "开头位置 &lt;= j"，仍然是倒着测，有助于及时break。&lt;/li&gt;
  &lt;li&gt;理想情况下时间等于关键词数目。&lt;/li&gt;
  &lt;li&gt;为了减少(da, dp)的报废数目（短时间报废过多会被迫等待继发封锁结束），可以使用“二级索引”的办法：分sqrt(len)块，然后再精确到块内的位置。这样只是时间*2。&lt;/li&gt;
 &lt;/ul&gt;
 &lt;li&gt;情况3、&amp;&amp;型关键词、可能有多个，求出所有关键词。&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;即使是求出其中的某一个关键词都是必须串行的，要花len的时间，难以忍受。但是实践中，.google.com &amp;&amp; ** 和 search &amp;&amp; ** 和 q=** 有可能同时是关键词，而询问作为www.google.com/search?q=**出现。由于此问题可由3-SAT规约到，是NPC问题，认为不可完成，所以从其它方面考虑：&lt;/li&gt;
  &lt;ul&gt;
   &lt;li&gt;1. 根据经验假设只会出现2个&amp;&amp;，但实现带任意多&amp;&amp;的关键词的匹配算法上并不困难，GFW应该有相应的计算能力。&lt;/li&gt;
   &lt;li&gt;2. 令s为{1..len}的一个随机置换，顺次考察s[i]，如果去掉后仍然触发就去掉，不再触发就保留。最后可以得到一个关键词。多路并行应该就可以求出所有关键词了。尽管到达每个关键词的概率不均匀，实践效果应该可以接受。&lt;/li&gt;
  &lt;/ul&gt;
 &lt;/ul&gt;
&lt;/ul&gt;

&lt;h4&gt;深度检测关键词和其他关键词检测&lt;/h4&gt;
&lt;p&gt;GFW对所有通信进行了全文关键词检测，并且可以对gzip、deflate压缩的报文实现实时解压缩判断。进行这种关键词检测，需要事先准备好被测试文本。如果是某网页或者某文件含有深度检测关键词，需要将相应文件下载到本地。与测试URL关键字不同之处就是文件可以非常大。上面的方法几乎行不通。但我们希望先缩小关键词的寻找范围。希望根据GFW的r或者ra包的序列号来定位出现关键词的两个包，这样被检测字符串的长度就被缩小到了不到3000字节，就可以套用上面的方法了。&lt;/p&gt;

&lt;p&gt;由于GFW的r和ra的seq是取自本地发出包的ack，只要对每个包按照发送顺序设置ack。&lt;/p&gt;
&lt;/fieldset&gt;

&lt;p&gt;坑了（事实上）。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-25314481385791363?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/25314481385791363/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2010/03/http-url.html#comment-form' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/25314481385791363'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/25314481385791363'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2010/03/http-url.html' title='HTTP URL/深度关键词检测'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>3</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-5410498851802273757</id><published>2010-03-10T07:25:00.000-05:00</published><updated>2010-03-10T07:25:05.710-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='DIY'/><title type='text'>西厢计划</title><content type='html'>&lt;p&gt;2008年7月tek4小组建立：&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;
作为个搞技术的人，我们要干点疯狂的事。如果我们不动手，我们就要被比我们差的远的坏技术人员欺负。这太丢人了。眼前就是，GFW这个东西，之前是我们不抱团，让它猖狂了。现在咱们得凑一起，想出来一个办法让它郁闷一下，不能老被欺负吧。要不，等到未来，后代会嘲笑我们这些没用的家伙，就象我们说别人“你怎么不反抗？”
&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;之后一个月几篇显著的文章出现：译言的《如何忽略防火长城》，周曙光的《&lt;a href="https://www.zuola.com/weblog/?p=1151"&gt;Zola教你玩：如何对抗GFW的域名劫持&lt;/a&gt;》，Robert Mao的《&lt;a href="http://robertmao.com/archives/976/"&gt;关于墙的技术讨论&lt;/a&gt;》 ，预言“射击墙的理论已经几乎要进入实战”。&lt;/p&gt;

&lt;p&gt;之后tek4小组又参与了绿坝&lt;del&gt;娘&lt;/del&gt;推倒作战，提供几份重要文档的来源。再之后GFW的实体被匿名网民进一步揭露，方滨兴浮出水面。&lt;/p&gt;

&lt;p&gt;时至今日，经过大家的努力，GFW的实体、结构、工作方式、弱点已经全部暴露在阳光之下，穿墙方法和DDoS规划方法也已经成熟。我们作为已经解散的tek4小组的一个分支，研究实际上在很早之前就已经结束，在花费大量时间编写文档、整理文献和验证实验数据之后，终于到了展示实战方法的时候，当初人们提出的设想也在这里得到了令人满意的答复。在这一部分完成之后我们也将解散。&lt;/p&gt;

&lt;p&gt;这就是：&lt;a href="http://code.google.com/p/scholarzhang/wiki/README"&gt;西厢计划&lt;/a&gt;。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-5410498851802273757?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/5410498851802273757/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2010/03/blog-post.html#comment-form' title='58 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/5410498851802273757'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/5410498851802273757'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2010/03/blog-post.html' title='西厢计划'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>58</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-3140817002926401289</id><published>2010-02-18T17:59:00.003-05:00</published><updated>2010-02-19T04:50:47.935-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='Understanding GFW'/><title type='text'>深入理解GFW：内部结构</title><content type='html'>&lt;p&gt;之前我们对GFW进行了大量的黑箱测试，尽管大多数实验数据都得到了良好的解释，但是还是有些数据或者体现出的规律性（不规律性）没有得到合理的解释。比如TCP连接的各项超时时间，比如Google的443端口被无状态阻断时，继发状态的持续跟源IP相关的问题。比如一般TCP连接的继发阻断时，窗口尺寸和TTL的连续变化特性。这些问题已经超出纯协议的范畴，需要对GFW的内部结构进行进一步了解才能明白其原因。所以在这一章介绍GFW的实现和内部结构。&lt;/p&gt;

&lt;p&gt;总的来说，GFW是一个建立在高性能计算集群上规模庞大的分布式入侵检测系统。其分布式架构带来了很高的可伸缩性，对骨干网一点上庞大流量的处理问题被成功转换成购买超级计算机堆砌处理能力的问题。它目前有能力对中国大陆全部国际网络流量进行复杂和深度的检测，而且处理能力“还有很大潜力”（2009年8月）&lt;sup&gt;&lt;a href="#null"&gt;[null]&lt;/a&gt;&lt;/sup&gt;。&lt;/p&gt;
&lt;a name='more'&gt;&lt;/a&gt;

&lt;h3&gt;线路接入&lt;/h3&gt;

&lt;img src="https://docs.google.com/File?id=dcg7wxzv_13c5hxczck_b" alt="典型意义下GFW线路拓扑" /&gt;&lt;div&gt;&lt;a href="https://docs.google.com/uc?id=0B0MUAMgaJJMfYmQzZWE0YjMtODA0YS00NWE0LWJmZGMtY2JjN2UwMzEzYzE2&amp;export=download"&gt;svg&lt;/a&gt;&lt;/div&gt;

&lt;p&gt;对于GFW在网络上的位置，有很模糊的认知：“在三个国际出口作旁路监听”。然而还希望对在出国之前最后一跳之前发生了什么有详细了解。&lt;/p&gt;

&lt;p&gt;GFW希望对不同线路的链路异构性进行耦合，并研究了快速以太网、低速WAN、光纤、专用信号多种类型链路的耦合技术。&lt;sup&gt;&lt;a href="#note-03b"&gt;[03b]&lt;/a&gt;&lt;/sup&gt;而根据《国际通信出入口局管理办法》，几大ISP有自己的国际出入口局，最后在公用国际光缆处汇合，比如在海缆登陆站之前汇合。据已有的资料，安管中心（CNNISC）有独立的交换中心，而且有报道说各个ISP是分别接入其交换中心。这样几个材料就可以形成一致的解释：为了适应不同ISP不同的链路规格，GFW自己的交换中心需要对不同的链路进行整合，不同的ISP分别引出旁路接入GFW。而没有接入GFW的线路则被称为“防外线”&lt;sup&gt;[来源不可靠]&lt;/sup&gt;，不受GFW影响。接入的线路类型应该主要是光纤线路，因此通常称此接入方式为分光。这就是“旁路分光”。另外实验发现，GFW的接入地点并不一定紧靠最后一跳，因此图中以虚线表示。需要注意GFW的响应流量重新接回网络的地点难以确认，这里只是假设是与接出的地点相同。&lt;/p&gt;

&lt;h3&gt;负载平衡&lt;/h3&gt;

&lt;p&gt;面对多条骨干监测线路接入产生的巨大不均匀流量，不能直接接到处理集群，而是要先进行汇聚然后再负载均衡分流成均匀的小流量，分别送给处理集群并行处理。首先需要将网络设备通信接口（Pos、ATM、E1等）转换成节点可用的主机通信接口（FE、GE等）。处理负载均衡的算法经过仔细考虑，希望实现：流量均匀分布、对于有连接协议保持连接约束、算法简单。连接约束是指：一对地址端口对之间的一个连接全部通信都要保证调度到同一个节点。&lt;sup&gt;&lt;a href="#note-03b"&gt;[03b]&lt;/a&gt;&lt;a href="#note-03a"&gt;[03a]&lt;/a&gt;&lt;a href="#note-05a"&gt;[05a]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;

&lt;p&gt;GFW关于负载平衡的文章中主要提出两种算法。一种是轮转调度，对于TCP，当SYN到达时，以最近分配的节点号取模再加1，并将连接存入hash表，当后继流量到达时就能查询hash表获得目标节点号。&lt;sup&gt;&lt;a href="#note-03a"&gt;[03a]&lt;/a&gt;&lt;/sup&gt;另一种是基于连接参数的散列，对于N个输出端口调度输出端口号是&lt;code&gt;H(源地址, 目标地址, 源端口, 目标端口) mod N&lt;/code&gt;&lt;sup&gt;&lt;a href="#note-03b"&gt;[03b]&lt;/a&gt;&lt;/sup&gt;，这个H函数可以是xor&lt;sup&gt;&lt;a href="#note-05a"&gt;[05a]&lt;/a&gt;&lt;/sup&gt;。&lt;/p&gt;

&lt;p&gt;而之前的某个实验中我们碰到一种特殊的模式，负载平衡在解释其现象中起到了重要作用，下面专门分出一节详细说明。&lt;/p&gt;

&lt;h3&gt;一个关于窗口值的实验&lt;/h3&gt;
&lt;p&gt;实验步骤：发送含有关键词的特制包通过GFW，并接收GFW返回的阻断响应包。因为触发阻断之后，同地址对和同目标端口的连接都会受到继发阻断，为了消除这种干扰，一般采取顺序改变目标端口的扫描式方法。通过前期一些实验，我们已经发现和确认某类（二型）阻断响应包中的TTL和id都跟窗口大小有线性关系，我们认为窗口是基本量（二型窗口为5042时id发生了溢出，只有在id根据窗口算出时才会发生此种情况）。&lt;/p&gt;

&lt;p&gt;然而在顺序扫描中有一种特殊的模式无法用现有证据解释。进一步的实验步骤是：在源、目标地址不变的情况下，顺序扫描目标端口，记录返回的阻断响应包的窗口。数据如下图，横轴是时间（秒），纵轴是端口号，每个点代表一次阻断触发事件中观测者收到的阻断包的窗口值。&lt;/p&gt;

&lt;img src="https://docs.google.com/File?id=dcg7wxzv_11f772fvgj_b" alt="实验图像"/&gt;

&lt;p&gt;可以明显看出一种线性增加的趋势。图像取局部放大看：&lt;/p&gt;

&lt;img src="https://docs.google.com/File?id=dcg7wxzv_12gdv2ppgf_b" alt="实验图像局部"/&gt;

&lt;p&gt;可以看出，在同一时间有13根较连续的线。这样产生了几个问题：为什么有独立可区分的不同的线？这些线表示了什么？为什么有13根？为什么每根线是递增的？&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;为什么有独立可区分的不同的线？现象具有明显的可以继续划分的子模式，而不是一个整体的随机量，并且每个子模式都有良好的连续增加的性质。因此可以推测产生此现象的内在机制不是一块铁板，而是多个独立的实体。进一步的实验事实是，如果顺序扫描端口每次增加13，那么只会产生一条较连续的线而排除其他的线。这直接证明了模13同余端口产生结果的不可分性、实体性，以及同余类间的独立性。&lt;/li&gt;
&lt;li&gt;这些线表示了什么？我们猜想，这13根线就表征了背后有13个独立实体分别根据某个内在的状态产生阻断响应，窗口值就是其内在状态的直接表现。&lt;/li&gt;
&lt;li&gt;为什么有13个？而不是1个2个？这个时候，负载平衡就是对此事实的一种解释良好的模型。如果GFW有13个节点在线，由于希望将流量平均分配到每个节点，那么根据前面论文所述，便采用模的方式，在源、目标地址不变时，根据目标端口模13分配流量，目标端口模13同余的包会进入同一个节点。实际上更早的时候的一次实验是发现有15根线，同理可以猜测有15个节点在线。&lt;/li&gt;
&lt;li&gt;为什么每根线是递增的？实验中发现，每次阻断GFW会分别向连接双方发送窗口值依次增加的两组阻断包，这样对于每方来说，每次阻断就会使窗口值增加2。每根线会递增正是说明节点在不断产生阻断包增加窗口值，一部分是实验观察者的观测行为触发的，另一部分则是普通网络流量造成的。如果对数据做差分并扣除观测造成的影响，甚至还可以对每节点产生阻断的速率有所估计。&lt;/li&gt;
&lt;li&gt;但是为什么要让窗口递增？这背后的动机难以找到很合理的解释，可能这个窗口值有计数器的作用，也可能是为了在ip.id上对不同节点产生的包进行区分。事实上，一型的窗口值就是几乎随机但ip.id固定，窗口递增并非是必须的。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;然而进一步的实验发现，如果目标端口、源地址不变，而目标地址顺序变化，图像就显得比较紊乱，找不出规律。虽然如此，仍然在局部可以识别出同时存在13根线的情况，进一步证实“13个节点在线”的猜测。这个实验的意义在于，通过对现象的分解约化，分离出GFW内部的某种独立实体结构，对论文中主张的负载平衡算法有进一步的实践证实，对GFW的内部结构得到进一步的认识。&lt;sup&gt;&lt;a name="ref-load-balance" href="#note-load-balance"&gt;[*]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;

&lt;h3&gt;数据处理&lt;/h3&gt;
&lt;p&gt;当数据流通过当数据总线到达终端节点之后，需要将其从物理层提取出来供上层进一步分析，这个部分称为报文捕获。普通的做法，先网卡中断一次通知内核来取，然后控制DMA传到内核空间，然后用户用&lt;code&gt;read()&lt;/code&gt;，让内核&lt;code&gt;copy_to_user()&lt;/code&gt;将sk_buff的数据复制到用户空间，但是这样复制一次就带来了无谓开销。因此GFW设计环状队列缓存，以半轮询半中断机制减少频繁中断的系统调用开销，用mmap实现zero-copy，把数据直接从网卡DMA到用户空间。这样性能提高很多（耦合也提高很多）。&lt;sup&gt;&lt;a name="ref-libpcap" href="#note-libpcap"&gt;[**]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;

&lt;p&gt;链路层数据到怀里了，接下来要将数据上交给TCP/IP栈。论文中多次提到libnids（这个库我们也是第一眼就瞟到了，后来发现对诊断没什么用），将其作为基准，（甚至可能符合国情地）以其为蓝本改进，开发出了一种多线程的TCP/IP（自动机）。后面又在考虑对其进一步做自动机分解优化。后来又再次提出一种两级连接状态记录表，一级轻量级环状hash表可以缓解大量无效连接和SYN Flood的情况，二级表才真正存储连接的信息。实验结果与此相符：发送SYN之后的超时时间要比发送第一个ACK之后的超时时间短得多。文献中还提到libnids的half_stream，从实际的情况上看，GFW的TCP栈的确具有鲜明的半连接特性，也就是说：一个方向的TCP栈只检测客户端到服务端的数据，或者反之。这样一个直接的后果就是，即使服务端根本不在线没响应，客户端照样可以假装三次握手然后触发一堆RST。往好的方向看，也许是因为多线程TCP栈还原全连接时不想处理数据共享控制的问题。总而言之，GFW有一种非常轻量级的TCP/IP栈，刚好能够处理大多数遵守RFC的连接。如果用户稍微精明一点就能穿过去，GFW要么坐视不管，要么重写TCP栈。&lt;sup&gt;&lt;a name="ref-tcp-stack" href="#note-tcp-stack"&gt;[***]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;

&lt;p&gt;TCP/IP栈将数据分片重组，流重组之后交给应用层解析。应用层由很多插件模块组成，耦合松，部署易。其应用层插件包括“HTTP、TELNET、FTP、SMTP、POP3、FREENET、IMAP、FREEGATE、TRIBOY”。&lt;sup&gt;&lt;a href="#note-05a"&gt;[05a]&lt;/a&gt;&lt;/sup&gt;有意思的是，这是首次官方确认GFW与Freegate、Freenet、Triboy的敌对关系。应用层的协议大家都很熟悉不用多解释，不过应用层问题比传输层更多了。好几个模块都有一些小毛病，比如某类HTTP模块只认得CRLF作为EOL，换作LF便呆了。再比如某类DNS模块，发的DNS干扰包，十有五六都校验和错误，查询AAAA也返回A，还不如关掉。多数模块都是得过且过，刚好可以工作，一点都不完善。这里列出的、发现的问题按照软件设计一般规律也只是冰山一角。由此推断，GFW的设计哲学是：&lt;cite&gt;better is worse&lt;/cite&gt;。&lt;/p&gt;

&lt;p&gt;不过在可以生产论文的话题上，GFW绝不含糊，就是模式匹配。应用层模块把应用层协议解析好了，然后就要看是不是哪里有关键词，字符串匹配。搞了一堆论文出来，改进AC算法和BM算法，就差汇编的干活了，得出某种基于有限状态自动机的多模式匹配算法，特别适合GFW这种预定义关键词的需求。总之复杂度是线性的，攻击匹配算法消耗CPU什么的就不要想了。&lt;/p&gt;

&lt;h3&gt;响应机制&lt;/h3&gt;
&lt;p&gt;如果匹配到一个关键词了，要积极响应阻断之。响应的手段其他地方已经说得太多，手懒，特此剽窃一段，欢迎举报学术不正之风：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;响应机制的发展已经经历IP包过滤（静态IP包过滤、动态IP包过滤）、连接欺骗（传输层连接欺骗、应用层连接欺骗）两个阶段，并且形成了针对不同的应用多种方式共存的现状。&lt;/p&gt;
&lt;p&gt;静态IP包过滤是IDS通过和被保护网络与外部网络之间的连通边的端点网络层设备（路由器、三层交换机等）进行联动，在其上设置访问控制列表（ACL）或静态路由表来实现对指定IP地址的过滤。由于需要过滤的IP地址数量很大，大多数的网络层设备上对ACL大小和性能的支持不能满足要求，因此，实际工作中大多采用静态路由的方式。使用该种方式，信息入侵检测系统只能通过专用客户端程序静态写入的方式进行访问控制，粒度大（IP地址级），响应时间慢，容量较小，但是可以静态写入路由设备的配置文件中，是非易失的。&lt;/p&gt;
&lt;p&gt;动态IP包过滤是指入侵检测系统采用动态路由协议（BGP，OSPF等）和关键路由设备进行路由扩散，将需要过滤的IP地址扩散到路由设备中的路由表中，特点是响应时间快、容量大，但是只能动态地写入路由设备内存（RAM）中的路由表中，是易失的，同样粒度大。&lt;/p&gt;
&lt;p&gt;连接欺骗指信息入侵检测系统在敏感连接传输过程中伪造连接结束信令（RST，FIN）发送给连接的源和目的地址，以中断该连接。特点是实时性强、粒度小（连接级），可以针对某一次敏感连接进行阻断。缺点是对分析系统工作状态依赖较强，需要向业务网上发送数据包，易受DoS攻击。&lt;/p&gt;
&lt;p&gt;通过和连接级防火墙设备进行联动，可以针对连接五元组（传输协议类型、源地址、源端口、目的地址、目的端口）对数据流进行过滤。可以针对指定的任意五元以内的组合条件进行过滤，实时性强、粒度小。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;后来又加上了DNS劫持/污染，不过这个手动设置的机制已经不能算一个入侵检测系统的响应了。&lt;/p&gt;

&lt;h3&gt;日志记录&lt;/h3&gt;
&lt;p&gt;GFW有日志。这意味着什么？这就意味着当你芬兰国的时候，你的所作所为都记录在案。不光是你一个人，其他所有人都经常芬兰国。但据统计87.53%的人（361之316）都是无意之中芬兰国，从统计理论上看，记录在案的无效信息过多会造成信息难以利用。因此GFW后期一直在做“数据融合、聚类、分类的研究”，鸭子硬上弓，各种神经网络、概率模型、人工智能的论文整了一大堆，效果如何呢？&lt;/p&gt;

&lt;p&gt;GFW的日志应该会记录这样一些事件信息：起始时间、结束时间、源地址、目标地址、目标端口、服务类型、敏感类型。&lt;sup&gt;&lt;a href="#null"&gt;[null]&lt;/a&gt;&lt;/sup&gt;信息难以利用不等于不能利用，如果日志被翻出来了而且用户没有用代理，那么根据常识，从IP地址对应到人也只是时间问题。这就是说，GFW即使不能阻断，最差也是一个巨型监听设备。&lt;/p&gt;

&lt;h3&gt;规模估计&lt;/h3&gt;
&lt;dl&gt;
 &lt;dt&gt;问题：&lt;/dt&gt;
 &lt;dd&gt;GFW的软硬件配置？&lt;/dd&gt;
 &lt;dt&gt;事实：&lt;/dt&gt;
 &lt;dd&gt;
  &lt;p&gt;“虚拟计算环境实验床”是由国家计算机网络应急技术处理协调中心（CNCERT/CC）和哈尔滨工业大学（HIT）协作建设，以国家计算机网络应急技术处理协调中心遍布全国31个省份的网络基础设施及计算资源为基础，对分布自治资源进行集成和综合利用，构建起的一个开放、安全、动态、可控的大规模虚拟计算环境实验平台，研究并验证虚拟计算环境聚合与协同机理。2005年此平台配置如下：&lt;sup&gt;&lt;a href="#note-05b"&gt;[05b]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
  &lt;table border="0"&gt;
   &lt;tr&gt;&lt;td&gt;CNCERT/CC&lt;/td&gt;&lt;td&gt;北京&lt;/td&gt;&lt;td&gt;曙光4000L&lt;/td&gt;&lt;td&gt;128节点&lt;/td&gt;&lt;td&gt;2*Xeon 2.4G&lt;/td&gt;&lt;td&gt;RAM2G&lt;/td&gt;&lt;/tr&gt;
   &lt;tr&gt;&lt;td&gt;HIT&lt;/td&gt;&lt;td&gt;哈尔滨&lt;/td&gt;&lt;td&gt;曙光服务器&lt;/td&gt;&lt;td&gt;32节点&lt;/td&gt;&lt;td&gt;2*Xeon 2.4G&lt;/td&gt;&lt;td&gt;RAM2G&lt;/td&gt;&lt;/tr&gt;
   &lt;tr&gt;&lt;td&gt;CNCERT/CC&lt;/td&gt;&lt;td&gt;上海&lt;/td&gt;&lt;td&gt;Beowulf集群&lt;/td&gt;&lt;td&gt;64节点&lt;/td&gt;&lt;td&gt;2*AMD Athlon 1.5G&lt;/td&gt;&lt;td&gt;RAM2G&lt;/td&gt;&lt;/tr&gt;
  &lt;/table&gt;
 &lt;/dd&gt;
 &lt;dt&gt;结论：&lt;/dt&gt;
 &lt;dd&gt;GFW（北京）使用曙光4000L机群，操作系统Red Hat系列（从7.2&lt;sup&gt;&lt;a href="#note-03a"&gt;[03a]&lt;/a&gt;&lt;/sup&gt;到7.3&lt;sup&gt;&lt;a href="#note-05a"&gt;[05a]&lt;/a&gt;&lt;/sup&gt;到AS 4），周边软件见曙光4000L一般配置；GFW实验室（哈工大）使用曙光服务器&lt;sup&gt;&lt;a href="#note-05b"&gt;[05b]&lt;/a&gt;&lt;/sup&gt;，Red Hat系列；GFW（上海）使用Beowulf集群（攒的？）。&lt;/dd&gt;
&lt;/dl&gt;
&lt;dl&gt;
 &lt;dt&gt;问题：&lt;/dt&gt;
 &lt;dd&gt;GFW与曙光是什么关系？&lt;/dd&gt;
 &lt;dt&gt;事实：&lt;/dt&gt;
 &lt;dd&gt;
  &lt;p&gt;换句话说，是先有了用户的应用需求（蛋），才有了曙光4000L的研制（鸡）。这其实不难想像，一套价值几千万元的系统，如果纯是为了填补科学空白，将会延长产品市场化的时间。曙光4000L充分体现了中科院计算所在科研成果市场化方面的运作能力。……而曙光4000L这套系统就是针对国家信息化的实际应用而设计的。&lt;/p&gt;
  &lt;p&gt;曙光4000L的研制……曙光公司从事了工程任务和产品化工作，国防科技大学从事了机群数据库中间件的开发工作，哈尔滨工业大学开发了应用软件。&lt;/p&gt;
  &lt;p&gt;哈尔滨工业大学（威海）网络与信息安全技术研究中心日前成立，……方滨兴……揭牌。……曙光……向研究中心赠送了一套价值40万元的刀片服务器。&lt;/p&gt;
 &lt;dt&gt;结论：&lt;/dt&gt;
 &lt;dd&gt;GFW是曙光4000L的主要需求来源、研究发起者、客户、股东、共同开发者。是不是应该打一点折？（曙光公司=中科院计算所）&lt;/dd&gt;
&lt;/dl&gt;
&lt;dl&gt;
 &lt;dt&gt;问题：&lt;/dt&gt;
 &lt;dd&gt;GFW计算规模有多大？&lt;/dd&gt;
 &lt;dt&gt;事实：&lt;/dt&gt;
 &lt;dd&gt;
  &lt;p&gt;2007年机群规模进一步扩大，北京增至360节点，上海增至128节点，哈尔滨增至64节点，共计552节点。机群间星型千兆互联。&lt;sup&gt;&lt;a href="#null"&gt;[null]&lt;/a&gt;&lt;/sup&gt;计划节点数上千。&lt;sup&gt;&lt;a href="#null"&gt;[null]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
  &lt;p&gt;曙光4000L……系统节点数为322节点，可扩展到640节点。根据功能的不同，曙光4000L可以分为服务节点、计算节点和数据库节点三类。每个计算节点2个2.4GHZ的Intel Xeon CPU，内存2GB。&lt;/p&gt;
  &lt;p&gt;2005年国家计算机网络与信息安全管理中心（北京）就已经建立了一套384*16节点的集群用于网络内容过滤（005工程）和短信过滤（016工程）。&lt;sup&gt;[来源不可靠]&lt;/sup&gt;&lt;/p&gt;
  &lt;p&gt;64个节点、128个处理器（主频为2.8GHz）的曙光4000L……包括系统软件、管理软件、输入输出设备和存储设备，采购金额近千万。&lt;/p&gt;
  &lt;p&gt;才有了曙光4000L的研制……一套价值几千万元的系统。&lt;/p&gt;
  &lt;p&gt;国家信息安全重大项目“国家信息安全管理系统”（005工程）经费4.9亿。&lt;/p&gt;
 &lt;dt&gt;猜测：&lt;/dt&gt;
 &lt;dd&gt;GFW（北京）拥有16套曙光4000L，每套384节点，其中24个服务和数据库节点，360个计算节点。每套价格约两千万到三千万，占005工程经费的主要部分。有3套（将）用于虚拟计算环境实验床，计千余节点。13套用于骨干网络过滤。总计6144节点，12288CPU，12288GB内存，峰值计算速度48万亿次（定义不明，GFW不做浮点运算，2003年top500排名榜首地球模拟器5120个CPU）。&lt;/dd&gt;
&lt;/dl&gt;
&lt;dl&gt;
 &lt;dt&gt;问题：&lt;/dt&gt;
 &lt;dd&gt;GFW吞吐量有多大？&lt;/dd&gt;
 &lt;dt&gt;事实：&lt;/dt&gt;
 &lt;dd&gt;
  &lt;p&gt;2GHz CPU的主机Linux操作系统下可达到600Kpps以上的捕包率。通过骨干网实验，配置16个数据流总线即可以线速处理八路OC48接口网络数据。&lt;sup&gt;&lt;a href="#note-03b"&gt;[03b]&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
  &lt;p&gt;曙光4000L单结点的接入能力为每秒65万数据包，整个系统能够满足32Gbp的实时数据流的并发接入要求。&lt;/p&gt;
 &lt;dt&gt;猜测：&lt;/dt&gt;
 &lt;dd&gt;512Gbps（北京）。&lt;/dd&gt;
&lt;/dl&gt;
&lt;h3&gt;结论&lt;/h3&gt;
&lt;p&gt;&lt;cite&gt;噫吁嚱！危乎高哉！……&lt;/cite&gt;&lt;/p&gt;


&lt;h3&gt;注释&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a name="null"&gt;null&lt;/a&gt;引用有特殊含义。&lt;/li&gt;
&lt;li&gt;&lt;a name="note-load-balance" href="#ref-load-balance"&gt;[*]&lt;/a&gt; 因为性能要求，负载平衡的完整算法必然很简单，不过我们一下子也没有猜出来。由于这个算法是易变的，即使猜出来公布在这里就立刻失效了，因此也没有在这个方向再费精力。&lt;/li&gt;
&lt;li&gt;&lt;a name="note-libpcap" href="#ref-libpcap"&gt;[**]&lt;/a&gt; 顺便指出论文中存在的一种硬伤。论文中反复把libpcap当反面教材作为性能低下的代表，称其是“传统TCP/IP栈之上的用户层函数库”“基于传统TCP/IP栈的libpcap”。可是人家libpcap从2001年1月的0.6版本就开始用2.2以上版本内核提供的packet(7) socket，这个跟TCP/IP一点关系都没有。怪罪的对象错了，要怪的是packet(7)而不是libpcap。后来2004年PF_RING出来，设计很相似，libpcap用上一样nb。不过这个时候GFW也已经研发完了。&lt;/li&gt;
&lt;li&gt;&lt;a name="note-tcp-stack" href="#ref-tcp-stack"&gt;[***]&lt;/a&gt; 如果将其视为bug而不是feature的话，漏洞实在太多，打一两个补丁不解决问题，非重做不可。另外IP碎片和TCP流重组没有做特别研究，即使有漏洞实用性也不会很高。&lt;/li&gt;
&lt;li&gt;&lt;a name="note-03a"&gt;[03a]&lt;/a&gt; 杨武, 方滨兴, 云晓春, 张宏莉. 基于骨干网的并行集群入侵检测系统. &lt;cite&gt;哈尔滨工业大学学报&lt;/cite&gt;. 2003-5-15.&lt;/li&gt;
&lt;li&gt;&lt;a name="note-03b"&gt;[03b]&lt;/a&gt; 陈训逊, 方滨兴, 李蕾. 高速网络环境下入侵检测系统结构研究. &lt;cite&gt;计算机研究与发展&lt;/cite&gt;. 2003-7-15.&lt;/li&gt;
&lt;li&gt;&lt;a name="note-05a"&gt;[05a]&lt;/a&gt; 张兆心, 方滨兴, 胡铭曾. 支持IDS的高速网络信息获取体系结构. &lt;cite&gt;北京邮电大学学报&lt;/cite&gt;. 2005-2-25.&lt;/li&gt;
&lt;li&gt;&lt;a name="note-05b"&gt;[05b]&lt;/a&gt; 张伟哲, 方滨兴, 胡铭曾, 刘欣然, 张宏莉, 高雷. 计算网格环境下基于多址协同的作业级任务调度算法. &lt;cite&gt;中国科学 E辑：信息科学&lt;/cite&gt;. 2005-12-25.&lt;/li&gt;
&lt;li&gt;猜测之数字准确性无担保，请自行把握。&lt;/li&gt;
&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-3140817002926401289?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/3140817002926401289/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2010/02/gfw.html#comment-form' title='90 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/3140817002926401289'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/3140817002926401289'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2010/02/gfw.html' title='深入理解GFW：内部结构'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>90</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-1729714560327468143</id><published>2010-02-18T17:57:00.000-05:00</published><updated>2010-02-18T17:57:34.463-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='about'/><category scheme='http://www.blogger.com/atom/ns#' term='motivation'/><title type='text'>评一条读者留言</title><content type='html'>&lt;p&gt;我们收到了一条有趣的&lt;a href="http://gfwrev.blogspot.com/2009/10/gfw.html#c2653228906027078580"&gt;留言&lt;/a&gt;：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;听前同事说起这个文章，今天闲得无聊上网来看下。感觉写这篇文章的老兄看来知道不少情况，但是有些东西的实情其实也并不清楚。举几个例子来说吧：&lt;br /&gt;
1、GFW的经费可比金盾工程的多了不知道几十倍！&lt;br/&gt;
2、方滨兴之流的根本就不是什么真正的技术专家，只是众多“叫兽”之一而已。（说实话，就方滨兴、云晓春、刘欣然之流的，他们那点儿技术水平都是给我当学生过来的。）&lt;br/&gt;
3、GFW的技术水平其实就像作者所说的那样，发现特征、阻断，不行的话就封IP，根本谈不到什么高水平。&lt;br/&gt;
4、CNCERT的技术支持一直就是启明星辰，连工作人员都是从启明星辰借调的。&lt;br/&gt;
&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;而在数十分钟之后，自曲新闻又有一条&lt;strong&gt;几乎&lt;/strong&gt;相同的留言，似乎这位留言者存在某种混淆。&lt;/p&gt;

&lt;p&gt;关于这条留言，我有一些看法：&lt;/p&gt;

&lt;a name='more'&gt;&lt;/a&gt;
&lt;ol&gt;
&lt;li&gt;可查证的资料显示，GFW的经费是十亿数量级的，而金盾工程是百亿数量级的。&lt;/li&gt;
&lt;li&gt;这位自称学术地位比方滨兴还要高，同时又使用“‘叫兽’”这样的语言，表达出一种随意而悠闲的思想感情，说明这位的身份是非常有意思的。&lt;/li&gt;
&lt;li&gt;关于GFW的技术水平，至少方滨兴等人的论文看起来并不激动人心，在研究过程中GFW经常会让人产生这样的感觉：“啊，为什么这里这么偷工减料。”虽然GFW背后的技术力量的确是中国顶尖的，但做出来的东西却不一定能够摆脱“山寨的本性”。&lt;/li&gt;
&lt;li&gt;启明星辰的确在GFW中起到重要作用，但是而启明星辰对GFW的作用到底怎么定性，只是运维，还是研发，还是参与技术决策？技术支持又是怎样一种角色？字面上理解，技术支持只是配角。总之这些情况因为保密不得而知，也许不同人看启明星辰的角色都有不同的角度。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;至于“但是有些东西的实情其实也并不清楚”，我想引一段话，出自人渣经济笔记：&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;在改革开放以前，中国对外界而言，基本就有点像一个黑洞——巨大但几乎没有什么可靠的信息出来，特别是中国经济的状况。几年前，哈佛的Dwight Perkins教授在他的非正式退休讲演中就说，改革开放以前，他和不少研究东亚和中国经济的经济学家，一直要做的一件事情就是，在官方数据不可得或者不可相信的情况下，估算中国经济的大小。 Perkins教授曾跟我说起，为了了解情况，他当年甚至读了不少可以收集到的大陆出版的小说。然后改革开放之后，中国一下开始公布这些数据了，Perkins教授开玩笑说：坏消息是我们这些多年的工作一下就没什么用了，好消息是我们发现当年我们猜得那些数据还是比较准确的。&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;事实上我们也是面对GFW这个黑洞从一片迷茫开始，阅读了大量公开可搜索的信息甚至&lt;a href="http://www.chinagfw.org/2009/08/gfw_21.html"&gt;科幻小说&lt;/a&gt;（今年3月份津妇联在何处崭露头角？ww），在理解能力之内对事实进行了最可能的估计。我们的确“对有些东西的实情并不清楚”，然而“清楚”或者对信息的占有并非一种值得夸耀的资本。我们在这里进行这样写作的目的，并非是作为某种“知道分子”（知道毛，知道不该知道的东西，爆米局就会曾经追查此事，无果）来传达或者泄漏某种专有的信息以显得自己对于GFW了解深厚，或者证明自己的推测是正确的。也许GFW体制内的人看着这样那样的推测会感到可笑，不过重要的并非一个人已经知道了什么，而是这个人将会知道些什么、能够知道些什么。读者能够指出文章中的错误是比文章本身更有价值的事情，因为价值在于思考和学习。&lt;/p&gt;

&lt;p&gt;这样一些系列从零到有的文章，是要展示一种对GFW进行全面理解的学习过程和方法，表达一种对GFW进行逆向工程的趣味。读者不应该仅仅作为一个信息的接收者，而是应该有自己积极的思考。如果读者中有百分之一开始自己思考关于GFW的问题，千分之一开始自己动手研究GFW，如果有万分之一开始将原理付诸实践，那就是很好的结果。如果所有人都只是伸手而没有动力去自行了解GFW，那么就只会让GFW越来越强大，而自己被动挨打被GFW追得到处跑。GFW在背后技术力量的推动下变动不居，不断地被更新、不断地发生变化，对GFW永远正确的认知或者一劳永逸的翻墙方法并不存在，只有与之对抗的方法和学习动力能留存下来。而这种动力并非来自某种对GFW的仇恨或者某种对言论自由的向往，而是一种简单的想法——“工部的走卒们，你们的这点把戏是难不倒我们的。”&lt;/p&gt;

&lt;h4&gt;展望一下未来&lt;/h4&gt;
&lt;p&gt;距上次文章已经过去了近几个月，这几个月发生了很多事情。在广电开始灭绝人性之前，我们曾认为中国互联网面临的最大威胁是强力的网络封锁，现在看来就算是能够分泌GDP的网络部门照样被一刀剁头，彻底关闭互联网反而是更加现实和直接的威胁。而最近超法规组织『中央政法委』的会议上放出的狠话更加强了这种预期。GFW越来越广泛地使用粗粒度的IP封锁策略，使得在网络层以上的努力都趋于无效。必须承认，私有SSH代理和私有VPN才是当前状况下的最优解决方案。但是由于这两种方法有较高的成本，其他一些低成本但有一些缺点的方法也暂时作为折中而继续存在研究价值。&lt;/p&gt;

&lt;p&gt;私有SSH代理和VPN可能遇到什么问题（VPS甚至托管主机就太高端这里不考虑）：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;提供SSH服务的提供商是有限可识别的，GFW在22端口（理论上可以做到端口无关）上检测SSH协议证书并阻断；效果不好时直接IP封锁。&lt;/li&gt;
&lt;li&gt;提供私有收费VPN服务的提供商也是有限可识别的，VPN协议比SSH稍复杂，直接用IP封锁。&lt;/li&gt;
&lt;li&gt;依据《商用密码管理条例》和《电子签名法》对密钥使用加强管理，对未备案的密钥和密码进行封锁。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;网络层可能会出现什么情况：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;发动网评员转职成网络巡查员，依靠自然智能人工检测目标，克服机器检测的简陋性，然后广泛使用黑洞路由封锁，让网络变得半残。&lt;/li&gt;
&lt;li&gt;借鉴伊朗的做法，在出入口用QoS或者直接限速，造成网络极为缓慢但又无法说断网了。（TPE都修好多久了，怎么出国带宽不见涨呢）&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;备战备荒&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;学习电话线上56K调制解调器的使用方法，在断网情况下能够在电话线路上开对等代理。&lt;/li&gt;
&lt;li&gt;留意拨号网络下的标准信息交流平台：各个telnet论坛。&lt;/li&gt;
&lt;li&gt;了解卫星上网知识，掌握卫星上网发展动向。&lt;/li&gt;
&lt;li&gt;在深圳的同学可以考虑搞微波通信或者激光大气通信跟对岸连起来，“以任何形式设置国际通信出入口”（大误&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;另外顺便说一点闲话，重新审阅了一下中文维基的防火长城条目，有这样一些错误，读者可以对比看看自己的观念中是不是还有这些误解：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;域名劫持的入侵检测系统与路由器无关。&lt;/li&gt;
&lt;li&gt;“已经封锁了几百个北美的DNS服务器”来源不可靠，OpenDNS和GoogleDNS从来都挺好的。&lt;/li&gt;
&lt;li&gt;IP封锁不在国际出入口，而在ISP级别的AS边界路由器。&lt;/li&gt;
&lt;li&gt;关键字过滤阻断不是在主干路由器上完成的，旁路。&lt;/li&gt;
&lt;li&gt;实现关键字过滤阻断的入侵检测系统是自主研制开发的，与思科无关。&lt;/li&gt;
&lt;li&gt;不存在省级GFW，正文所述实验不严谨，结论错误；实际上由不同TTL判断出的那个所谓的“省级”GFW是我们所称的“二型”——TTL随时序连续变化。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;因为维基百科的非原创研究方针所以我也懒得去改了，这些都是没有来源的原创研究。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-1729714560327468143?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/1729714560327468143/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2010/02/blog-post.html#comment-form' title='11 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/1729714560327468143'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/1729714560327468143'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2010/02/blog-post.html' title='评一条读者留言'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>11</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-7184144153699280693</id><published>2010-01-22T18:21:00.000-05:00</published><updated>2010-01-22T18:21:57.641-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='off-topic'/><title type='text'>搜索引擎安全管理系统</title><content type='html'>&lt;p&gt;看到一则不起眼的资料：&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;搜索引擎安全管理系统&lt;br/&gt;
完成人：刘欣然；方滨兴；齐向东；李伍峰；石晓虹；刘正荣；杨臻；丁丽；张鸿；陈斌&lt;br/&gt;
单位： 国家计算机网络与信息安全管理中心；北京三际无限网络科技有限公司；国务院新闻办公室互联网新闻研究中心&lt;br/&gt;
日期：2005年2月2日&lt;br/&gt;
简介：该系统提供了第三方的基于HTTP标准的规范高性能过滤接口，在输入和输出两个环节分三级进行有效的信息过滤；提供了统一管理平台，可以远程进行管理，经单点配置过滤策略即可实现全局同时生效，且策略下发过程可保证对过滤目标的保密要求系统可以采用分布式或集中式的部署结构。系统接入简单，易于部署，适用于绝大多数现有的搜索引擎，可以满足现有国内日查询量的处理要求。该系统已实际部署一些国内较大的搜索引擎，取得了良好的使用效果。全面推广和部署该系统，将为净化国内互联网空间提供有力保障。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;一点事实：当时刘欣然、方滨兴是安管中心的研究人员和负责人，而安管中心是GFW的运维单位；李伍峰、刘正荣是中国最大网络审查机构国新办的网络部门负责人；齐向东、石晓虹是三际无限公司的高管，而该公司则是360安全卫士的开发者。&lt;/p&gt;

&lt;p&gt;我们知道国内的搜索引擎都有关键词过滤，通常认为这是搜索引擎的自我审查。然而最近有一些案例发现在某些情况下不同搜索引擎的“自我审查”会同时失效，说明背后并不简单。以上资料说明了这样几个事实：&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;存在一个对国内搜索引擎进行统一关键词过滤的审查管理系统，其被称为“搜索引擎安全管理系统”；&lt;/li&gt;
&lt;li&gt;这个系统是主要由GFW的运维单位安管中心（CNCERT/CC）开发；&lt;/li&gt;
&lt;li&gt;这个系统主要需求和日常使用来自国新办，有密级；&lt;/li&gt;
&lt;li&gt;国内搜索引擎的关键词过滤有一部分是由国新办直接操作的“非自我审查”；&lt;/li&gt;
&lt;li&gt;360安全卫士的开发者三际无限公司也参与了这个系统的开发。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;三际无限公司的所作所为已经不仅仅是“将用户隐私信息交给政府安全部门”；它协助CNCERT、积极参与建设对国内互联网的审查机制，为长城添砖加瓦，这已经超出作恶的范畴，可称得上助纣为虐。加之之前报道称360安全卫士将自由门等软件检测为恶意软件，这个公司的道德水准已经昭然若揭。请丝毫不要怀疑三际无限与审查部门和安全部门的良好关系，请丝毫不要惊讶安全部门会通过360安全卫士对用户进行监听。&lt;/p&gt;

&lt;p&gt;另引用&lt;a href="http://opinion.huanqiu.com/roll/2010-01/696893.html" title="互联网成为美国霸权主义的又一武器"&gt;双想范文&lt;/a&gt; [huanqiu.com] 一段：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;为掩人耳目，中情局成立了一家高科技公司，以民间身分为幌子与谷硅高科技公司合作开发能够从互联网上获取任何内容的间谍软件。间谍软件以捆绑方式和其他软件一起当用户安装实用软件时它悄悄地进行自动安装。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;哼哼。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-7184144153699280693?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/7184144153699280693/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2010/01/blog-post.html#comment-form' title='46 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/7184144153699280693'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/7184144153699280693'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2010/01/blog-post.html' title='搜索引擎安全管理系统'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>46</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-5014327600578182966</id><published>2009-11-27T04:43:00.001-05:00</published><updated>2009-11-27T10:06:41.940-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='Understanding GFW'/><title type='text'>深入理解GFW：DNS污染</title><content type='html'>&lt;h3&gt;初识DNS污染&lt;/h3&gt;
&lt;p&gt;翻墙新手们往往遇到这样的问题：我明明已经设置了socks代理为127.0.0.1:xxxx，为什么还是上不去youtube？这时经验丰富的翻墙高手就会告诉你：firefox需要设置network.proxy.socks_remote_dns为true，也就是远程解析域名。这是怎样一回事呢？为什么要远程解析？这就涉及到了GFW的DNS污染技术。&lt;/p&gt;

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

&lt;a name='more'&gt;&lt;/a&gt;

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

&lt;h4&gt;伪包特征&lt;/h4&gt;

&lt;p&gt;经过一番&lt;strong&gt;紧密&lt;/strong&gt;的查询，我们可以发现GFW返回的IP取自如下列表：&lt;/p&gt;
&lt;pre&gt;
4.36.66.178
203.161.230.171
211.94.66.147
202.181.7.85
202.106.1.2
209.145.54.50
216.234.179.13
64.33.88.161
&lt;/pre&gt;
&lt;p&gt;关于这八个特殊IP，鼓励读者对这样两个问题进行探究：1、为什么是特定的IP而不是随机IP，固定IP和随机IP各自有什么坏处；2、为什么就是这8个IP不是别的IP，这8个IP为什么倒了GFW的霉？关于搜索这类信息，除了&lt;a href="http://www.google.com/ncr" title="Google 英文"&gt;www.google.com&lt;/a&gt;之外，&lt;a href="http://www.bing.com/search?q=&amp;amp;mkt=en-US&amp;amp;setlang=match" title="Bing 英文"&gt;www.bing.com&lt;/a&gt;有专门的搜索IP对应网站的功能，使用方法是输入&lt;code&gt;ip:&lt;var&gt;IP地址&lt;/var&gt;&lt;/code&gt;搜索。&lt;a href="http://www.robtex.com"&gt;www.robtex.com&lt;/a&gt;则是一个专门收集域名解析信息的网站。欢迎读者留下自己的想法和发现:lol:。&lt;/p&gt;

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

&lt;ul&gt;
 &lt;li&gt;一型：&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;ip_id == ____（是一个固定的数，具体数值的查找留作习题）。&lt;/li&gt;
  &lt;li&gt;没有设置“不分片”选项。&lt;/li&gt;
  &lt;li&gt;没有设置服务类型。&lt;/li&gt;
  &lt;li&gt;对同一对源IP、目标IP，GFW返回的污染IP在上述8个中按照给出的顺序循环。与源端口无关、与源IP目标IP对相关。&lt;/li&gt;
  &lt;li&gt;TTL返回值&lt;strong&gt;比较&lt;/strong&gt;固定。TTL为IP头部的“Time to Live”值，每经过一层路由器这个值会减1，TTL为1的IP包路由器将不再转发，多数路由器会返回源IP一条“ICMP time to live exceed in transit”消息。&lt;/li&gt;
 &lt;/ul&gt;
 &lt;li&gt;二型：&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;每个包重复发送3次。&lt;/li&gt;
  &lt;li&gt;没有设置“不分片”选项。&lt;/li&gt;
  &lt;li&gt;设置了“保障高流量”服务类型。&lt;/li&gt;
  &lt;li&gt;(ip_id + ? * 13 + 1) % 65536 == 0，其中?为一个&lt;strong&gt;有趣的未知数&lt;/strong&gt;。ip_id在同一个源IP、目标IP对的连续查询之间以13为单位递减、观测到的ip_id的最小值和最大值分别为65525（即-11，溢出了!）和65535。&lt;/li&gt;
  &lt;li&gt;对同一对源IP、目标IP，GFW返回的污染IP在上述8个中按照给出的顺序循环。与源端口无关、与源IP目标IP对相关。&lt;/li&gt;
  &lt;li&gt;对同一对源IP、目标IP，TTL返回值时序以1为单位递增。TTL在GFW发送时的取值有64种。注：源IP接收到的包的TTL被路由修改过，所以用户观测到的TTL不一定只有64种取值，这是由于网络拓扑变化的原因导致的。一型中的“&lt;strong&gt;比较&lt;/strong&gt;固定”的“比较”二字也是考虑到网络拓扑偶尔的变化而添加的，也许可以认为GFW发送时的初始值是恒定的。&lt;/li&gt;
 &lt;/ul&gt;
&lt;/ul&gt;

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

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

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

&lt;ul&gt;
 &lt;li&gt;一型&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;DNS应答包的ANSWER部分的RR记录中的域名部分由0xc00c指代被查询域名。&lt;/li&gt;
  &lt;li&gt;RR记录中的TTL设置为5分钟。&lt;/li&gt;
  &lt;li&gt;无论用户查询的TYPE是什么，应答包的TYPE总是设置为A（IPv4地址的意思）、CLASS总是设置为IN。&lt;/li&gt;
 &lt;/ul&gt;
 &lt;li&gt;二型&lt;/li&gt;
 &lt;ul&gt;
  &lt;li&gt;DNS应答包的ANSWER部分的RR记录中的域名部分是被查询域名的全文。&lt;/li&gt;
  &lt;li&gt;RR记录中的TTL设置为1天。&lt;/li&gt;
  &lt;li&gt;RR记录中的TYPE和CLASS值是从源IP发送的查询复制的。&lt;/li&gt;
 &lt;/ul&gt;
&lt;/ul&gt;
其中的术语解释：RR = Resource Record：dns数据包中的一条记录；RDATA = Resource Data：一条记录的数据部分；TYPE：查询的类型，有A、AAAA、MX、NS等；CLASS：一般为IN[ternet]。&lt;br&gt;

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

&lt;h4&gt;现状分析&lt;/h4&gt;

&lt;ul&gt;
 &lt;li&gt;4.36.66.178，关键词。whois：Level 3 Communications, Inc. 位于Broomﬁeld, CO, U.S.&lt;/li&gt;
 &lt;li&gt;203.161.230.171，关键词。whois：POWERBASE-HK位于Hong Kong, HK.&lt;/li&gt;
 &lt;li&gt;211.94.66.147，whois：China United Network Communications Corporation Limited位于Beijing, P.R. China.&lt;/li&gt;
 &lt;li&gt;202.181.7.85，关键词。whois：First Link Internet Services Pty Ltd.位于North Rocks, AU.&lt;/li&gt;
 &lt;li&gt;202.106.1.2,whois：China Unicom Beijing province network位于Beijing, CN.&lt;/li&gt;
 &lt;li&gt;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.&lt;/li&gt;
 &lt;li&gt;216.234.179.13，关键词。反向解析为IP-216-234-179-13.tera-byte.com。whois：Tera-byte Dot Com Inc.位于Edmonton, AB, CA.&lt;/li&gt;
 &lt;li&gt;64.33.88.161，反向解析为tonycastro.org.ez-site.net, tonycastro.com, tonycastro.net, thepetclubfl.net。whois：OLM,LLC位于Lisle, IL, U.S.&lt;/p&gt;
&lt;/ul&gt;

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

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

&lt;ul&gt;
 &lt;li&gt;例如倒霉的edoors.cn.china.cn，宁波中国门业网，其实是因为edoors.cn被dns污染。一起受害的还有chasedoors.cn.china.cn，美国蔡斯门业（深圳）有限公司。&lt;/li&gt;
 &lt;li&gt;还有*.sf520.com，似乎是一个国内的游戏私服网站。www.sf520.com也是一个私服网站。可见国内行政体系官商勾结之严重，一个“国家信息安全基础设施”竟然还会用来保护一些网游公司的利益。&lt;/li&gt;
 &lt;li&gt;此外还有一些个人blog。www.99tw.net也是一个游戏网站。&lt;/li&gt;
 &lt;li&gt;还有www.why.com.cn，名字起得好。&lt;/li&gt;
 &lt;li&gt;还有www.999sw.com 广东上九生物降解塑料有限公司生物降解树脂|增粘母料|高效保水济|防洪 邮编:523128……这又是怎么一回事呢？不像是被什么反动网站连坐的。还有人问怎么回事怎么会有那么多IP结果。&lt;/li&gt;
 &lt;li&gt;www.facebook.comwww.xiaonei.com，怎么回事呢？其实是因为有人不小心把两个地址连起来了，搜索引擎以为这是一个链接，其实这个域名不存在，但是解析的时候遭到了污染，就以为存在这个域名了。&lt;/li&gt;
 &lt;li&gt;倒霉的www.xinsheng.net.cn——武汉市新胜电脑有限公司，因为www.xinsheng.net被连坐。&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;DNS劫持的防范和利用&lt;/h3&gt;
&lt;p&gt;之前我们已经谈到，GFW是一套入侵检测系统，仅对流量进行监控，暂没有能力切断网络传输，其“阻断”也只是利用网络协议容易被&lt;a href="http://zh.wikipedia.org/wiki/%E4%BC%9A%E8%AF%9D%E5%8A%AB%E6%8C%81"&gt;会话劫持&lt;/a&gt;（&lt;a href="http://en.wikipedia.org/wiki/Session_hijacking"&gt;Session hijacking&lt;/a&gt;）的弱点来进行的。使用无连接UDP的DNS查询只是被GFW抢答了，真正的答案就跟在后面。于是应对GFW这种攻击很自然的想法就是：&lt;/p&gt;
&lt;blockquote&gt;根据时序特性判断真伪，忽略过早的回复。&lt;/blockquote&gt;
&lt;p&gt;通常情况对于分别处于GFW两端的IP，其&lt;a href="http://en.wikipedia.org/wiki/Round-trip_time"&gt;RTT&lt;/a&gt;（Round-trip time，往返延迟）要大于源IP到GFW的RTT，可以设法统计出这两个RTT的合适的均值作为判断真伪的标准。另外由于GFW对基于TCP的DNS请求没有作处理，于是可以指定使用TCP而不是UDP解析域名。也可以通过&lt;strong&gt;没有部署GFW的线路&lt;/strong&gt;到&lt;strong&gt;没有被DNS污染的NS&lt;/strong&gt;进行查询，例如文章一开始提到的“远程解析”。但黑体字标出的两个条件缺一不可，例如网上广为流传的&lt;strong&gt;OpenDNS可以反DNS劫持的说法是以讹传讹&lt;/strong&gt;，因为到OpenDNS服务器的线路上是经由GFW的。&lt;/p&gt;

&lt;p&gt;本质的解决办法是给DNS协议增加验证机制，例如DNSSEC（&lt;a href="http://en.wikipedia.org/wiki/DNSSEC"&gt;Domain Name System Security Extensions&lt;/a&gt;），客户端进行递归查询（Recursive Query）而不查询已经被污染了的递归解析服务器（&lt;a href="http://en.wikipedia.org/wiki/Authoritative_name_server#Recursive_and_caching_name_server"&gt;Recursive/caching name server&lt;/a&gt;）。然而缺点是目前并非所有的权威域名解析服务器（&lt;a href="http://en.wikipedia.org/wiki/Authoritative_name_server#Authoritative_name_server"&gt;Authoritative name server&lt;/a&gt;）都支持了DNSSEC。&lt;a href="http://www.unbound.net/"&gt;Unbound&lt;/a&gt;提供了一个这样的带DNSSEC验证机制的递归解析程序。&lt;/p&gt;

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

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

&lt;h3&gt;参考文献&lt;/h3&gt;

&lt;ol&gt;
&lt;li&gt;闫伯儒, 方滨兴, 李斌, 王垚. "DNS欺骗攻击的检测和防范". &lt;cite&gt;计算机工程&lt;/cite&gt;, 32(21):130-132,135. 2006-11.&lt;/li&gt;
&lt;li&gt;Graham Lowe, Patrick Winters, Michael L. Marcus. &lt;a href="http://cs.nyu.edu/%7Epcw216/work/nds/final.pdf"&gt;The Great DNS Wall of China&lt;/a&gt;. 注：这篇文章虽然试图通过统计特性了解GFW，但由于实验条件控制不佳、实验结果观察不细致，加上缺乏对GFW的&lt;strong&gt;整体观&lt;/strong&gt;，故没有提供什么有意义的结论。然而美国同学的这种科学态度与实验精神值得我们学习和思考。事实上，这篇文章仍然提供了珍贵的历史资料，读者不妨按照本文逻辑来分析这篇参考文献。阅读过这篇文献的&lt;strong&gt;敏感&lt;/strong&gt;的读者还将在我们后续的文章中看到熟悉的数字。&lt;/li&gt;
&lt;li&gt;KLZ毕业. &lt;a href="http://www.chinagfw.org/2009/09/gfw_21.html"&gt;入侵防御系统的评测和问题&lt;/a&gt;. 注：本文对DNS污染包的分类就是从这篇文章的分类继承而来。&lt;/li&gt;
&lt;/ol&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-5014327600578182966?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/5014327600578182966/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfwdns.html#comment-form' title='9 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/5014327600578182966'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/5014327600578182966'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfwdns.html' title='深入理解GFW：DNS污染'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>9</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-5409210981447122652</id><published>2009-11-25T00:23:00.000-05:00</published><updated>2009-11-25T00:23:53.507-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='parody'/><title type='text'>漫谈国家安全与“个人安全”【转】</title><content type='html'>&lt;p&gt;复旦大学的国际政治系博士沈逸写了一篇文章《Twitter之战》。文意大概是在表明，twitter在接受“美国国务院为伊朗用户推迟原定维护计划的建议”之后已经变成美国政府进行渗透颠覆的工具。这在某种程度上反映了党内很大一部分同志的想法，以前新华社也发过不少类似揭露渗透颠覆的文章。这并不是一件好事情，我们有些党员干部对信息时代的新事物不理解，维稳这件事情做得粗暴简单缺乏策略。有些同志在八九风波之后就一直处于“颠覆性歇斯底里”的状态，稍微听到一点逆言便视其为煽动颠覆、敌对势力，凡是都站在国家安全的角度考虑，用国家暴力机器进行打击。这种焦虑是要不得的，反映出一些党员干部抱着国家安全不愿意了解新事物、畏惧新事物的心态。新的舆论阵地如果我们不先抢占，就要被敌人抢占。被敌人抢占之后才意识到，然后再来修防火墙搞封锁实乃下策，反而不能实现最好的国家安全。&lt;/p&gt;

&lt;a name='more'&gt;&lt;/a&gt;

&lt;p&gt;我们的媒体宣传建设亟待加强。我们的网评员不理解网络文化，说话官八股说教味道浓厚，不能深入群众，不能与群众互动，在网络上常常被网民围攻。我们对外的窗口外交部，发表的言论总也摆脱不了文革语言的陈腐气息，给国际社会留下古板的印象。我们的官员，“不明真相的群众”“一小撮”“别有用心”之类的话说了几十年，最后反而被群众嘲笑。这些都反映出我们一些同志思维僵化，思想懒惰，不解放思想、与时俱进。我们总是指责美国的冷战思维，其实这些同志凡事以维稳安全为中心的思想才是最大的冷战思维。如果我们不尽快赶上时代发展，掌握先进的生产力，积极建设河蟹网络社会，在网络发展中发挥积极作用，反而只是消极地封堵网络有害信息，坐看时代前行，那我党的先进性将如何保证？&lt;/p&gt;

&lt;p&gt;沈逸博士作为我国著名大学研究国际政治的学者，论及国际政治不能体现出一个大国的自信，反而处处渲染国家即将被外国敌对势力颠覆的焦虑，这并不是居安思危，而是杞人忧天。事实上，我国从十年前开始的国家安全建设迄今已经取得了长足的进步和令人民自豪的诸多成果，国家安全也得到了强大的保护。这样的建设成果为什么避而不谈？闷声发大财是我们的优良传统，但是也要因时因地根据具体情况辩证地进行判断。&lt;/p&gt;

&lt;p&gt;首先，《Twitter之战》一文中提到的“美国政府隐秘地监控着所有访问伊斯兰极端主义网站的网络浏览记录”，就是指美国国家安全局NSA的“恐怖分子监视计划”。其实这个所谓的“恐怖分子监视计划”无论其技术还是其规模，都不能和我国国家计算机网络与信息安全管理中心的“国家信息安全管理系统”相媲美。我国的这个完全自主研发、自主知识产权高新系统，仅依靠北京、上海、广州三地的三个交换中心，便可对全中国出入的所有网络流量进行深度包检测，将所有非法信息记录在案并根据设置适时进行阻断，而且目前还有巨大计算潜力闲置供未来使用。而我们公安部建设的金盾工程，仅从投资额看规模就比国家信息安全管理系统大十倍以上，简直是在全中国布下一张天网，让所有犯罪分子无所遁形。&lt;/p&gt;

&lt;p&gt;其次，NSA的监听受到美国立法机构若干法令的严重限制，在布什总统批准下对恐怖分子进行监听反而被舆论猛烈抨击。而我们的公安干警国安干警在有关法律法规的支持下对敌对分子进行监听则不会受到反动媒体的干扰，那些以“防火长城”之词对国家安全事业进行攻击的敌对媒体都会被严肃处理和封锁。而且美国关押危害美国国家安全的恐怖分子这样明显的内政常常受到国际社会的严重阻挠，而我国依法打击处理危害国家安全的敌对分子的内政则不会有国家妄图阻挠，如果有，我们的外交部也会予以驳斥。种种现象都说明，在国家信息安全领域的建设上，我国已经领先于超级大国美国，在对抗美国霸权主义的斗争中占据了上风。&lt;/p&gt;

&lt;p&gt;最近，有越来越多的潜伏的敌对分子试图编写“个人安全网络隐私”的手册来与国家安全体系对抗，实际上在强大的国家安全体系之下这些措施都不堪一击。中国有句古话叫作，要想人莫知除非己莫为，在信息时代这句话依然成立，靠的就是日志。用户通过ISP联网会产生日志，用户访问网站会产生日志，在使用网络服务（论坛、即时通讯、电子邮件等等）的时候也会产生日志，用户的网络流量经过金盾工程的监听设备和国家信息安全管理系统的监听设备也会产生日志，用户的固定和移动电话通讯会产生日志。按照有关规定，这些日志都要详细保存九十天以上。这样，混杂在人民群众中的一小撮就在这些日志上留下了大量的蛛丝马迹，即使想避免，也是不可能的，因为我们的国家安全体系就像《黑客帝国》中的史密斯侦探一样无处不在。&lt;/p&gt;

&lt;p&gt;我们的国家安全体系总是有一层神秘的面纱，下面就让我们走进伪科学来解开这个不解之谜。我们可以从两个阶段来看国家安全体系对犯罪分子的监控，第一个阶段是发现，第二个阶段是控制。&lt;/p&gt;

&lt;p&gt;发现就是要将从一个人的网络身份定位到这个人的真名实姓。首先可以说，只要确定了IP地址，那么这个人的真实身份便几乎确定了，实际上从IP到真实身份往往是侦查的最后一步。我国的民用网络服务方式主要是基于电话线的ADSL和网吧这两种。前者由于计费的需要，分配的IP一定要与实名的帐号挂钩并记录在案，我们在新闻报道中常常看到，公安干警在侦查网络犯罪发现犯罪分子IP地址之后便会向ISP调取有关记录，非常快捷方便。而后者也很显然，虽然网吧内部是局域网，单机具有网络层匿名性，但是经过几年的治理，全国的网吧已经建立起一套完善的管理体系，上网记录直接与身份证号挂钩，要调取记录也是非常方便的。&lt;/p&gt;

&lt;p&gt;其次，从应用层到IP地址也是不难实现的。如果通过被动调查、钓鱼等方式确定犯罪分子访问过国内的任意网站和网络服务，公安干警便可以向有关的ICP调取访问日志获取IP进行筛查。国内即时通讯服务的日志记录更加完善，我们也看到不少新闻报道，犯罪分子通过QQ等在线聊天工具策划犯罪的通话内容被悉数记录在案。如果犯罪分子比较狡猾，不访问国内的网站，只访问国外的网站甚至用国外的匿名代理来访问国内会怎么样呢？我们同样可以通过强大的金盾和国信安系统截获其明文通信。我们知道，仅仅国信安系统可以对全国所有国际流量进行深度关键词检测，甚至经过gzip压缩也同样可以检测，而且漏报率极低，金盾更是遍布全国。那么最简单的做法就是将与犯罪分子网络身份直接相关的一些字符串（比如用户名、邮箱地址）设为只记录不阻断的关键词进行监听。最后通过统计各种特征的匹配次数，发现那个匹配次数最高的几个IP，并且结合犯罪分子的网络上“社会网络”的活动特点，再进行实地确认，便可查出犯罪分子的真实身份。这种朴素的方法一般被称作筛查，通过不断去除数据中的噪音缩小范围，虽然可行但往往耗时耗力，所以中科院计算所和哈工大也在为这方面的安全事业开展数据挖掘的研究，目的就是要从海量的日志数据中查出关联性，以便更加迅速有效地定位犯罪分子。&lt;/p&gt;

&lt;p&gt;一些老奸巨猾的犯罪分子和境外专业的颠覆集团会使用境外服务器加密代理的手段来试图逃脱记录，我们的安全体系面对这样的敌人并非毫无办法。首先境外提供代理服务的公司都会有相应的规定要配合国际刑事调查，特别是那些免费加密/VPN代理尤为如此。其次如果犯罪分子购买境外服务必然产生国际交易，这也可以通过调取银行的有关记录来进行调查，缩小侦查范围。而且即使无法监听加密通信内容，加密通信的地址、时间、流量等特征也是可以观测的。这样通过一系列措施拉长了犯罪分子的步骤，使得犯罪分子的行为产生漏洞的可能性更大。&lt;/p&gt;

&lt;p&gt;一旦完成了真实身份的确认，如果有放长线的需要，那么接下来的控制阶段就显得势如破竹。我们知道，明文通信的监听是非常成熟的，前面已经讨论过。而常见的加密通信所依赖的公钥体系在中间人的攻击之下也是非常脆弱的，而且我国的PKI也可以适应国家安全的需要对特殊的用户进行个别的设置。就算犯罪分子不依赖公钥体系自行设置密钥，我们是不是也能通过国家级的计算集群暴力破解？虽然公开的报告都认为这难度较大，但实际上也不排除弱密钥被破解的可能性。除了这些被动监听的方法，公安干警还可以采用技术手段，向犯罪分子的电脑中种植木马、甚至rootkit，这样都可以更有效地获取犯罪分子策划犯罪的信息。&lt;/p&gt;

&lt;p&gt;总而言之，一些潜伏中的敌对分子以所谓“个人安全”妄图挑战国家安全的力量我们已经看到这无异于螳臂当车。当然，上面描述这些侦查手段都会有成本，为了节省纳税人的税款，要采取针对不同威胁级别的目标有不同等级的优化措施，这些都应该因时因地制宜。而且我们还要依法进一步推进网络实名制的建设，以便更有效地打击网络犯罪和网络有害信息。值得警惕的是一种新型的去中心化匿名组织，以美国的“4chan”论坛为代表，这类论坛组织往往随意发动“raid”、组织群体性事件，难以追查组织者和参与者，危害极大，需要早发现、早防范、早处置落实三“早”。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-5409210981447122652?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/5409210981447122652/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/11/blog-post.html#comment-form' title='10 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/5409210981447122652'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/5409210981447122652'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/11/blog-post.html' title='漫谈国家安全与“个人安全”【转】'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>10</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-6044826177005793540</id><published>2009-11-10T03:09:00.005-05:00</published><updated>2009-11-10T03:22:15.616-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='DIY'/><title type='text'>GFW研究与诊断工具</title><content type='html'>&lt;p&gt;在开始所有对GFW的细致研究之前，要先给大家介绍一下我们研究所需要的主要工具和典型方法。读者也可以留言推荐自己喜欢的工具。&lt;/p&gt;

&lt;p&gt;一览：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;监听和扫描：wireshark，tcpdump，nmap&lt;/li&gt;
&lt;li&gt;应用层：nc，wget，curl，w3m&lt;/li&gt;
&lt;li&gt;编程接口：libpcap/winpcap，libnids，libnet/raw sockets，snort，libnetfilter*(libipq)/divert sockets&lt;/li&gt;
&lt;/ul&gt;

&lt;a name='more'&gt;&lt;/a&gt;

&lt;h4&gt;监视和诊断工具&lt;/h4&gt;
&lt;p&gt;我们需要一些工具来进行一般性的人工流量监视，人工报文检查，因此需要一些用户界面的工具。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;wireshark&lt;/strong&gt;是报文监听的“业界标准”。建议以&lt;a href="http://wiki.wireshark.org/CaptureSetup/CapturePrivileges"&gt;非root帐号运行&lt;/a&gt;wireshark。如果版本不支持，可以手动设置（linux）：&lt;/p&gt;
&lt;blockquote&gt;
&lt;code&gt;addgroup --quiet --system wireshark&lt;/code&gt;&lt;br/&gt;
&lt;code&gt;chown root:wireshark dumpcap&lt;/code&gt;&lt;br/&gt;
&lt;code&gt;chmod u=rwxs,g=rx,o=r /usr/bin/dumpcap # dumpcap是wireshark的听包接口&lt;/code&gt;
&lt;code&gt;usermod -G wireshark -a $USER # 将自己加入wireshark组&lt;/code&gt;
&lt;/blockquote&gt;
&lt;p&gt;然后重新登录生效。&lt;a href="http://wiki.wireshark.org/Lua#head-cc34cd978b51eb601a0e005647af2528fd946da1" title="Lua in wireshark"&gt;设置&lt;/a&gt;一个lua后解析器从而能够自动标示GFW的伪造包。修改&lt;code&gt;/etc/wireshark/init.lua&lt;/code&gt;，将&lt;code&gt;disable_lua = true&lt;/code&gt;一行注释掉。将&lt;a href="http://docs.google.com/View?id=dcg7wxzv_59n34swzv"&gt;gfw.lua&lt;/a&gt;复制到&lt;code&gt;~/.wireshark/init.lua&lt;/code&gt;，并禁用TCP协议解析中的相对序列号和窗口缩放特性。设置两个着色规则，分别为&lt;code&gt;gfw.type == 1&lt;/code&gt;和&lt;code&gt;gfw.type == 2&lt;/code&gt;，选取喜欢的颜色，置顶。在&lt;code&gt;/etc/hosts&lt;/code&gt;中为本地IP地址静态设置一个域名，比如&lt;samp&gt;Local&lt;/samp&gt;，并设置网络层解析这样可以遮住IP地址。&lt;/p&gt;

&lt;blockquote&gt;
约定：在之后的文章中的wireshark截屏着色规则，一型颜色为白底红字，二型颜色为浅黄底红字。
&lt;/blockquote&gt;
&lt;p&gt;比如一次典型的&lt;code&gt;w3m www.google.com/search?q=&amp;lt;关键词&amp;gt;&lt;/code&gt;：&lt;/p&gt;

&lt;div&gt;&lt;a href="http://docs.google.com/View?id=dcg7wxzv_59n34swzv"&gt;&lt;img src="http://docs.google.com/File?id=dcg7wxzv_6hdjwwzf7_b" style="width: 100%" /&gt;&lt;/a&gt;&lt;/div&gt;

&lt;p&gt;我们可以清晰地看到，这次会话被GFW伪造的一个一型RST和三个二型RST/ACK阻断。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;tcpdump&lt;/strong&gt;可以在无图形界面的时候作监听，但可视化效果很差，令人眼花缭乱。可以将流量转储，待之后用wireshark分析。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;nmap&lt;/strong&gt;适于大范围快速扫描，可以用其脚本功能增强嗅探能力，比如扫描Google的网段有哪些IP的443端口被干扰了。但nmap不适于细致的诊断和探索性研究，其脚本功能不够强大，网络层的发包听包能力也比较局限。&lt;/p&gt;

&lt;h4&gt;探索和构造工具&lt;/h4&gt;
&lt;p&gt;我们需要通过一些构造性的工具，设计特殊的包和特殊的对照试验来对GFW进行逆向工程，试图了解GFW的特性和工作机制。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;wget&lt;/strong&gt;、&lt;strong&gt;curl&lt;/strong&gt;、&lt;strong&gt;w3m&lt;/strong&gt;都是应用层的标准HTTP工具，看用户自己的喜好。不过由于wget的&lt;a href="http://savannah.gnu.org/bugs/index.php?20416"&gt;bug #20416&lt;/a&gt;，HTTP诊断所需的“下载部分内容”的功能必须靠curl -r来实现。主要用于HTTP协议及以上的探索。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;nc&lt;/strong&gt;是TCP/IP瑞士军刀。用脚本+nc要比走套接字五步曲方便得多。可以用来进行应用层任意协议的研究，比如构造畸形HTTP头探查协议解析漏洞。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;libnet&lt;/strong&gt;、&lt;strong&gt;raw socket&lt;/strong&gt;可以用来在网络层和传输层构造包。前者的包构造接口比较方便简单；如果希望不使用第三方库则raw(7)也可实现同样功能；如果没有TCP offload功能，可以把libnet算校验和的代码偷过来。适合做入侵检测漏洞实验。另外还可以看看libdnet。&lt;/p&gt;

&lt;h4&gt;入侵检测工具&lt;/h4&gt;
&lt;p&gt;入侵检测简单说无非就是对报文进行更加细致的检测。前面我们通过人工看wireshark可以实现研究性的“入侵检测”，在研究定型之后要根据研究结果进行自动化的入侵检测，于是便要用到这些工具。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;libpcap&lt;/strong&gt;/&lt;strong&gt;winpcap、&lt;/strong&gt;&lt;strong&gt;raw socket&lt;/strong&gt;可以用来在网络层听包。raw(7)的好处是已经由操作系统的IP栈做好了IP包分片组装、接口规范（socket(7)、raw(7)）、可以获得原始的时间戳。Winsock的接口不太规范，觉得Winsock的文档比较糟糕，Windows下还是winpcap比较方便。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;libnids&lt;/strong&gt;提供了一个TCP/IP栈，需结合*pcap使用。有基本的传输层入侵检测能力，接口比较友好文档比较齐全。适合做一些轻量级的入侵检测。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;snort&lt;/strong&gt;是“业界标准”的入侵检测系统，自带仔细编写的TCP/IP栈，入侵检测功能和扩展能力都很强大，可以扩展成为入侵检测平台，可与周边的&lt;em&gt;免污染DNS解析器&lt;/em&gt;、&lt;em&gt;HTTP代理自动配置平台&lt;/em&gt;、&lt;em&gt;本地路由配置&lt;/em&gt;等工具高度整合，协同对抗GFW的干扰。但是仅研究的话，由于其规则太专用化、不够通用，难以进行一般性的入侵检测实验。需要自行编写动态组件，但是这方面文档比较缺乏，耦合度很高，需要彻底研究其代码后尚能动工，难度较大。snort 3.0实现了lua脚本，功能值得期待。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;libnetfilter*&lt;/strong&gt;(Linux)、&lt;strong&gt;divert sockets&lt;/strong&gt;(FreeBSD)可以在用户态直接操作TCP/IP栈，是进行入侵检测和响应最直接、最基于目标（target-based）、最强大的方式。内联snort（snort-inline）便基于libipq（被libnetfilter*取代）或divert sockets，进行报文丢弃、拒绝、数据修改替换等强大动作。适合在研究定型之后以其编写专门入侵防御软件来对抗GFW干扰，要比libpcap+libnet强大许多。继续往下走进内核写内核模块（网卡驱动）来做这方面的入侵防御就过于牛刀杀鸡、耦合性过高，不提了。&lt;/p&gt;

&lt;h4&gt;HTTP关键词诊断&lt;/h4&gt;

&lt;p&gt;被重置连接，为什么？只要花上十分钟&lt;strong&gt;一定能&lt;/strong&gt;找到原因。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1. 现象：点击链接立即被重置连接&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;原因：URL里含有关键词，GFW伪造的重置包在对方应答之前到达。&lt;/p&gt;

&lt;p&gt;一般通过人工近似的二分法来找关键词。比如&lt;samp&gt;http://zh.wikipedia.org/wiki/燃烧瓶&lt;/samp&gt;访问被重置，诊断步骤：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;找任一个可以访问的无关国外（国内）站点，确认其不处于90秒继发阻断状态（可直接访问）；&lt;/li&gt;
&lt;li&gt;将被阻断的URL作为路径直接访问，比如&lt;samp&gt;http://ti.com/zh.wikipedia.org/wiki/燃烧瓶&lt;/samp&gt;，结果也被阻断，我们可以确认此URL至少含有一个关键词；&lt;/li&gt;
&lt;li&gt;反复尝试缩短范围，去除无关部分，直到长度短到令人满意；&lt;/li&gt;
&lt;li&gt;验证关键词充要性，尝试删去关键词任一部分，比如这里删去头部的&lt;samp&gt;z&lt;/samp&gt;或者尾部的&lt;samp&gt;瓶&lt;/samp&gt;，结果都可正常访问，说明已无子关键词串；&lt;/li&gt;
&lt;li&gt;按照一般的认知，以/为间隔符分别测试是否存在多个关键词的逻辑与关系，比如&lt;samp&gt;http://ti.com/燃烧瓶 &amp;amp;&amp;amp; zh.wikipedia.org/wiki/&lt;/samp&gt;没有被阻断，我们认为不存在关键词与关系；&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;这样我们就确定&lt;samp&gt;zh.wikipedia.org/wiki/燃烧瓶&lt;/samp&gt;是一个“充要”的关键词。（以上多用到经验，并非严格证明，特别是关键词存在性逻辑关系的证明是比较麻烦的）&lt;/p&gt;

&lt;p&gt;常见问题和经验：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;关键词不充要，还可以缩短。比如曾经有人发现&lt;samp&gt;为什么&lt;/samp&gt;是关键词，其实&lt;samp&gt;什么&lt;/samp&gt;是关键词。&lt;/li&gt;
&lt;li&gt;关键词要在一个由.+域名+路径组成的URL字串内匹配。比如&lt;samp&gt;.bbc.co.uk/chinese&lt;/samp&gt;是关键词，但&lt;samp&gt;.bbc.co.uk&lt;/samp&gt;和&lt;samp&gt;chinese&lt;/samp&gt;都不是关键词。但是如果直接访问&lt;samp&gt;bbc.co.uk/chinese&lt;/samp&gt;仍然被阻断，因为最前面被加上一个.才进行匹配的，访问&lt;samp&gt;http://ti.com/bbc.co.uk/chinese&lt;/samp&gt;便无事。&lt;/li&gt;
&lt;li&gt;关键词中域名常常以.开头。比如&lt;samp&gt;.bbc.co.uk/chinese&lt;/samp&gt;是关键词，但&lt;samp&gt;bbc.co.uk/chinese&lt;/samp&gt;不是关键词。这样可以有效封锁子域名而避免其他有相同后缀的域名被误伤，比如&lt;samp&gt;.youtube.com&lt;/samp&gt;是关键词，则不能访问&lt;samp&gt;*.youtube.com&lt;/samp&gt;，但可以访问&lt;samp&gt;loveyoutube.com&lt;/samp&gt;。不过需要注意，域名与URL其他成分&lt;strong&gt;地位一样&lt;/strong&gt;，不会被特别处理。&lt;/li&gt;
&lt;li&gt;关键词可能含有&lt;strong&gt;逻辑与&lt;/strong&gt;关系。比如&lt;samp&gt;立法会&lt;/samp&gt;不是关键词，但&lt;samp&gt;search&lt;/samp&gt;与&lt;samp&gt;立法会&lt;/samp&gt;同时出现在URL中就触发阻断，再比如&lt;samp&gt;纳米比亚 &amp;amp;&amp;amp; 胡海峰&lt;/samp&gt;。这个逻辑与是&lt;strong&gt;可交换&lt;/strong&gt;的，一般记作&lt;code&gt;A &amp;amp;&amp;amp; B&lt;/code&gt;。通常在Google搜索被重置时要考虑&lt;samp&gt;search&lt;/samp&gt;。三个以上词的与也有，比如&lt;samp&gt;.google. &amp;amp;&amp;amp; great &amp;amp;&amp;amp; firewall&lt;/samp&gt;。&lt;/li&gt;
&lt;li&gt;关键词可能含有特殊字符，不要想当然以特殊字符为分隔进行二分搜索。比如以前的&lt;samp&gt;search?q=cache&lt;/samp&gt;，现在的&lt;samp&gt;q=freedom&lt;/samp&gt;。&lt;/li&gt;
&lt;li&gt;URL的百分号编码会在进行匹配之前被解码，不应考虑为另一个关键词；一个关键词在实现上可能同时存在两种编码的表示，比如GBK和UTF8（当然只是二进制流的差别，对用户来说这个是透明的）。&lt;/li&gt;
&lt;li&gt;服务器返回重定向指令的Location字段同样受到URL关键词检测，对此的诊断需要监听流量。&lt;/li&gt;
&lt;li&gt;安全问题，每次撞墙都被GFW记录在案，所以在进行探索和验证试验之前需要仔细考虑何种信息被记录及其后果。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;2. 现象：页面打开一半被重置、或者尾部不能显示刷新被立即重置&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;原因：页面含有深度检测关键词，GFW伪造的重置包在一段时间后赶上了序列号增加进度成功重置连接，并附加90秒继发阻断。&lt;/p&gt;

&lt;p&gt;例：英语维基的&lt;a href="http://en.wikipedia.org/wiki/Golden_Shield_Project"&gt;Golden Shield Project&lt;/a&gt;条目被封锁不能正常打开，访问页面载入一部分后连接被重置。我们希望找到原因。由于页面内容十分多，靠二分查找比较慢，我们可以通过监听流量来初步缩小范围。&lt;/p&gt;

&lt;p&gt;用wireshark监听一次浏览器常规访问，禁用浏览器的gzip压缩功能以简化监听。&lt;/p&gt;

&lt;div&gt;&lt;a href="http://docs.google.com/View?id=dcg7wxzv_59n34swzv"&gt;&lt;img src="http://docs.google.com/File?id=dcg7wxzv_7crdqm9cg_b" style="width: 100%" /&gt;&lt;/a&gt;&lt;/div&gt;

&lt;p&gt;（38帧之前情况正常，省略之；数据有时效性，仅作示例用）&lt;/p&gt;

&lt;p&gt;我们看到了GFW的伪造包（47开始）。进行序列分析：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;GFW检测到对方发来的包含有关键词；&lt;/li&gt;
&lt;li&gt;希望伪装为对方重置连接；&lt;/li&gt;
&lt;li&gt;在关键词触发现场发出RST，根据上下文为RST包设置合法的序列号：&lt;em&gt;关键词包的序列号&lt;/em&gt;加上&lt;em&gt;关键词包的荷载长度&lt;/em&gt;。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;由此可以判断：在上图中&lt;strong&gt;47帧和53帧是39帧触发的&lt;/strong&gt;，这样我们就把范围缩小到1348字节。&lt;/p&gt;

&lt;p&gt;这1348字节的绝对位置：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;http-body开始的TCP包的序列号是486312304（不在图中）；&lt;/li&gt;
&lt;li&gt;导致阻断的包序列号是486332524、荷载长1348；&lt;/li&gt;
&lt;li&gt;这1348字节是从http-body的20220偏移开始（486332524 - 486312304）。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;我们可以利用HTTP的“下载部分内容”特性，并结合先验知识和二分法在这1348字节中寻找、判断和验证关键词。下图是这样两次命令的情况：&lt;/p&gt;
&lt;blockquote&gt;
&lt;code&gt;curl -r 21394-21397 http://en.wikipedia.org/wiki/Golden_Shield_Project&lt;/code&gt;&lt;br/&gt;
&lt;code&gt;curl -r 21394-21398 http://en.wikipedia.org/wiki/Golden_Shield_Project&lt;/code&gt;
&lt;/blockquote&gt;

&lt;div&gt;&lt;a href="http://docs.google.com/View?id=dcg7wxzv_59n34swzv"&gt;&lt;img src="http://docs.google.com/File?id=dcg7wxzv_8hd5999f7_b" style="width: 100%" /&gt;&lt;/a&gt;&lt;/div&gt;

&lt;p&gt;这样我们就验证了，处于页面21394-21398字节的&lt;samp&gt;Falun&lt;/samp&gt;是条目被阻断的&lt;strong&gt;充分条件&lt;/strong&gt;（严格而论还需验证&lt;samp&gt;alun&lt;/samp&gt;，不过此处从略）。至于页面中是否含有其他关键词这次不再深入，由于深度检测的范围很广，要人工证明必要性要困难一点。&lt;/p&gt;

&lt;p&gt;由于GFW对维基百科进行的深度检测比较特殊，是单向的（从服务端到客户端），我们无法仅仅通过向服务端提交含有深度关键词的内容来触发深度检测查找关键词，所以只能通过HTTP协议提供的下载部分内容方法。有一些深度检测关键词是全局双向的，比如dongtaiwang.com，这种关键词可以通过POST附带二分的内容来寻找，不过一般遇不到这种关键词。&lt;/p&gt;

&lt;p&gt;总而言之，这个找关键词的问题是理论上有解的。&lt;/p&gt;

&lt;h4&gt;DNS劫持诊断&lt;/h4&gt;

&lt;p&gt;先查到该域名的DNS权威服务器，一般权威服务器的域名是没有被污染的，否则就去根服务器查。然后直接向权威服务器发查询，比如&lt;/p&gt;
&lt;blockquote&gt;
&lt;code&gt;host www.youtube.com ns1.google.com&lt;/code&gt;
&lt;/blockquote&gt;

&lt;div&gt;&lt;a href="http://docs.google.com/View?id=dcg7wxzv_59n34swzv"&gt;&lt;img src="http://docs.google.com/File?id=dcg7wxzv_9c3jkgm2w_b" style="width: 100%" /&gt;&lt;/a&gt;&lt;/div&gt;

&lt;p&gt;（黑底红字表示校验和错误，本地发的包不对是因为UDP offload）&lt;/p&gt;

&lt;p&gt;哪些是真包，哪些是伪包一目了然。（GFW的DNS劫持模块做得真是偷懒啊，看看那些精美的[Malformed Packet]）如果不一目了然，那可以看时间戳。&lt;/p&gt;

&lt;p&gt;最后提一下IP封锁的诊断。一般是用基于ICMP的traceroute看哪里路由断了；如果没有ICMP可以靠网页版的诊断工具，比如&lt;a href="http://www.just-ping.com"&gt;just-ping&lt;/a&gt;。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-6044826177005793540?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/6044826177005793540/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfw_10.html#comment-form' title='13 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/6044826177005793540'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/6044826177005793540'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfw_10.html' title='GFW研究与诊断工具'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>13</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-8422683895879378574</id><published>2009-11-05T00:47:00.000-05:00</published><updated>2009-11-05T00:47:20.315-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='Understanding GFW'/><title type='text'>深入理解GFW：路由扩散技术</title><content type='html'>&lt;p&gt;GFW的重要工作方式之一是在网络层的针对IP的封锁。事实上，GFW采用的是一种比传统的&lt;strong&gt;访问控制列表&lt;/strong&gt;（Access Control List，&lt;strong&gt;ACL&lt;/strong&gt;）高效得多的控制访问方式——&lt;strong&gt;路由扩散技术&lt;/strong&gt;。分析这种新的技术之前先看看传统的技术，并介绍几个概念。&lt;/p&gt;

&lt;h4&gt;访问控制列表（ACL）&lt;/h4&gt;

&lt;p&gt;ACL可以工作在网络的二层（链路层）或是三层（网络层），以工作在三层的ACL为例，基本原理如下：想在某个路由器上用ACL控制（比如说是切断）对某个IP地址的访问，那么只要把这个IP地址通过配置加入到ACL中，并且针对这个IP地址规定一个控制动作，比如说最简单的丢弃。当有报文经过这个路由器的时候，在转发报文之前首先对ACL进行匹配，若这个报文的目的IP地址存在于ACL中，那么根据之前ACL中针对该IP地址定义的控制动作进行操作，比如丢弃掉这个报文。这样通过ACL就可以切断对于这个IP的访问。ACL同样也可以针对报文的源地址进行控制。如果ACL工作在二层的话，那么ACL控制的对象就从三层的IP地址变成二层的MAC地址。从ACL的工作原理可以看出来，ACL是在正常报文转发的流程中插入了一个匹配ACL的操作，这肯定会影响到报文转发的效率，如果需要控制的IP地址比较多，则ACL列表会更长，匹配ACL的时间也更长，那么报文的转发效率会更低，这对于一些骨干路由器来讲是不可忍受的。&lt;/p&gt;

&lt;h4&gt;路由协议与路由重分发&lt;/h4&gt;

&lt;/p&gt;而GFW的网络管控方法是利用了OSPF等路由协议的&lt;strong&gt;路由重分发&lt;/strong&gt;（&lt;strong&gt;redistribution&lt;/strong&gt;）功能，可以说是&lt;strong&gt;“歪用”&lt;/strong&gt;了这个本来是正常的功能。&lt;/p&gt;

&lt;a name='more'&gt;&lt;/a&gt;

&lt;h4&gt;动态路由协议&lt;/h4&gt;
&lt;p&gt;说路由重分发之前先简单介绍下动态路由协议。正常情况下路由器上各种路由协议如OSPF、IS-IS、BGP等，各自计算并维护自己的路由表，所有的协议生成的路由条目最终汇总到一个路由管理模块。对于某一个目的IP地址，各种路由协议都可以计算出一条路由。但是具体报文转发的时候使用哪个协议计算出来的路由，则由路由管理模块根据一定的算法和原则进行选择，最终选择出来一条路由，作为实际使用的路由条目。&lt;/p&gt;

&lt;h4&gt;静态路由&lt;/h4&gt;
&lt;p&gt;相对于由动态路由协议计算出来的动态路由条目，还有一种路由不是由路由协议计算出来的，而是由管理员手工配置下去的，这就是所谓的静态路由。这种路由条目优先级最高，存在静态路由的情况下路由管理模块会优先选择静态路由，而不是路由协议计算出来的动态路由。&lt;/p&gt;

&lt;h4&gt;路由重分发&lt;/h4&gt;
&lt;p&gt;刚才说到正常情况下各个路由协议是只维护自己的路由。但是在某些情况下比如有两个AS（自治系统），AS内使用的都是OSPF协议，而AS之间的OSPF不能互通，那么两个AS之间的路由也就无法互通。为了让两个AS之间互通，那么要在两个AS之间运行一个域间路由协议BGP，通过配置，使得两个AS内由OSPF计算出来的路由，能通过BGP在两者之间重分发。BGP会把两个AS内部的路由互相通告给对方AS，两个AS就实现了路由互通。这种情况就是通过BGP协议重分发OSPF协议的路由条目。&lt;/p&gt;

&lt;p&gt;另外一种情况，管理员在某个路由器上配置了一条静态路由，但是这条静态路由只能在这台路由器上起作用。如果也想让它在其他的路由器上起作用，最笨的办法是在每个路由器上都手动配置一条静态路由，这很麻烦。更好的方式是让OSPF或是IS-IS等动态路由协议来重分发这条静态路由，这样通过动态路由协议就把这条静态路由重分发到了其他路由器上，省去了逐个路由器手工配置的麻烦。&lt;/p&gt;

&lt;h4&gt;GFW路由扩散技术的工作原理&lt;/h4&gt;
&lt;p&gt;前面说了是“歪用”，正常的情况下静态路由是由管理员根据网络拓扑或是基于其他目的而给出的一条路由，这条路由最起码要是&lt;strong&gt;正确&lt;/strong&gt;的，可以引导路由器把报文转发到正确的目的地。而GFW的路由扩散技术中使用的静态路由其实是一条&lt;strong&gt;错误的路由，而且是有意配置错误的&lt;/strong&gt;。其目的就是为了把本来是发往某个IP地址的报文统统引导到一个&lt;strong&gt;“黑洞服务器”&lt;/strong&gt;上，而不是把它们转发到正确目的地。这个黑洞服务器上可以什么也不做，这样报文就被无声无息地丢掉了。更多地，可以在服务器上对这些报文进行分析和统计，获取更多的信息，甚至可以做一个虚假的回应。&lt;/p&gt;

&lt;h4&gt;评价&lt;/h4&gt;
&lt;p&gt;有了这种新的方法，以前配置在ACL里的每条IP地址就可以转换成一条故意配置错误的静态路由信息。这条静态路由信息会把相应的IP报文引导到黑洞服务器上，通过动态路由协议的路由重分发功能，这些错误的路由信息可以发布到整个网络。这样对于路由器来讲现在只是在根据这条路由条目做一个常规报文转发动作，无需再进行ACL匹配，与以前的老方法相比，大大提高了报文的转发效率。而路由器的这个常规转发动作，却是把报文转发到了黑洞路由器上，这样既提高了效率，又达到了控制报文之目的，手段更为高明。&lt;/p&gt;

&lt;p&gt;这种技术在正常的网络运营当中是不会采用的，错误的路由信息会扰乱网络。正常的网络运营和管控体系的需求差别很大，管控体系需要屏蔽的IP地址会越来越多。正常的网络运营中的ACL条目一般是固定的，变动不大、数量少，不会对转发造成太大的影响。而这种技术直接频繁修改骨干路由表，一旦出现问题，将会造成骨干网络故障。&lt;/p&gt;

&lt;p&gt;所以说GFW是歪用了路由扩散技术，正常情况下没有那个运营商会把一条错误的路由信息到处扩散，这完全是歪脑筋。或者相对于正常的网络运营来说，GFW对路由扩散技术的应用是一种小聪明的做法。正常的路由协议功能被滥用至此，而且非常之实用与高效，兲朝在这方面真是人才济济。&lt;/p&gt;

&lt;h4&gt;&lt;a href="/search/label/GFW-metrics"&gt;测量&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;GFW动态路由系统概括起来就是：人工配置(c)样本路由器(sr)的静态路由(r)，向各ISP的出入口路由器(or)扩散此路由(r)，将特定网络流量转到黑洞服务器(fs)进行记录。因此可以进行测量的项目有：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;(r)被封锁的IP列表：可以通过协作报告机制收集用户报告，也可通过扫描著名站点获得；（传言：GFW动态路由系统的容量是几十万条规则）&lt;/li&gt;
&lt;li&gt;(or)受到GFW影响的ISP出入口路由器：通过在广域多ISP内的节点协作traceroute可以测得；&lt;/li&gt;
&lt;li&gt;(or)-(c)从关键词生效到动态路由生效的延迟：通过建立蜜罐并提交给GFW然后观察其响应；&lt;/li&gt;
&lt;li&gt;(fs)黑洞服务器的健壮性：用伪源噪音流量对黑洞服务器进行填充，观测其响应。&lt;/li&gt;
&lt;/ul&gt;

&lt;h4&gt;参考文献&lt;/h4&gt;
&lt;p&gt;刘刚, 云晓春, 方滨兴, 胡铭曾. "一种基于路由扩散的大规模网络控管方法". &lt;cite&gt;通信学报&lt;/cite&gt;, 24(10): 159-164. 2003.&lt;/p&gt;
&lt;p&gt;李蕾, 乔佩利, 陈训逊. "一种IP访问控制技术的实现". &lt;cite&gt;信息技&lt;/cite&gt;术, (6). 2001.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-8422683895879378574?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/8422683895879378574/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfw_05.html#comment-form' title='7 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/8422683895879378574'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/8422683895879378574'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfw_05.html' title='深入理解GFW：路由扩散技术'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>7</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-3991579747292607369</id><published>2009-11-02T17:00:00.003-05:00</published><updated>2009-11-03T23:32:39.924-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='GFW-metrics'/><category scheme='http://www.blogger.com/atom/ns#' term='Social Engineering'/><title type='text'>GFW钓鱼计划</title><content type='html'>&lt;p&gt;社会工程从来都是在安全领域最有趣味的话题。钓鱼（phishing）是社会工程的一种。最近韩寒童鞋揭露了出现在上海的某种钓鱼小把戏，我们也不妨来讨论一下某种GFW钓鱼小把戏。面对GFW这个黑箱，我们希望对它的内部的行政机制有所了解，这当然是技术性的逆向工程无法解决的问题，所以这里主要讨论社会工程的方法。&lt;/p&gt;

&lt;h4&gt;原理&lt;/h4&gt;
&lt;p&gt;对GFW进行黑箱式分析，就会发现一种非常确定的刺激-反应的行为模式。一般来说是这样的过程：1）一个网站处于含有敏感内容的状态；2）在某个时刻GFW感知到这个网站（“先期侦察”）并受到刺激；3）然后通过GFW内部的某种过程；4）最后形成对这个网站的封锁反应。一般只有最后的封锁反应是公开可观测的GFW特征，然而由于GFW的封锁采取伪造的方式进行，我们很难从这种封锁动作中获得信息。而如果我们特制一个网站并作为网站控制者让GFW对它进行感知，并&lt;strong&gt;利用GFW自认为置身暗处而不采取防护的漏洞&lt;/strong&gt;，那么在刺激这个环节就很有可能观测到GFW的真实信息。简而言之GFW你不是特别会封吗？这次我造一个网站让你封，来啊。然后将GFW在这个环节泄漏的信息全部记录下来。这就是钓鱼，有人也把这个叫做蜜罐，在蜜罐里放一些GFW特别喜欢的东西，苍蝇循着香味飞进来就黏住了。根据先验知识我们还可以知道，在对目标进行侦察之后，GFW内部还会有关于反应方式的评估。这个过程虽然是无法观测的，不过当蜜罐收集到的数据量比较充分之后进行分析，就会找到这个过程的某些模式，分离出时间周期、地域、主题偏好等要素，对GFW内部的机制有一个轮廓性的刻画。&lt;/p&gt;

&lt;a name='more'&gt;&lt;/a&gt;

&lt;h4&gt;方法&lt;/h4&gt;
&lt;p&gt;在8月份我们就进行了这样一次钓鱼。钓鱼有这么几个要件：诱饵，钩子，鱼，渔。在这里鱼是GFW，渔是我们，诱饵是一个充满了敏感词的网站，钩子是这个网站内置的日志记录器。诱饵的建设是体力活，比较麻烦，行为跟spammer差不多了。首先寻找国外的免费空间和免费域名，然后用一个php+.htaccess/mod_rewrite做一个网页反向代理，代理到某个特别敏感的网站，然后php内置日志记录器将访问时间和访问者的IP地址和HTTP头全部记录下来。网站看起来是一模一样的，差别只在域名，这就建好了。然后到伟大光荣正确的国新办网站&lt;a href="http://safesurf.china.cn/data_form.php" title="中国互联网违法和不良信息举报中心"&gt;net.china.cn&lt;/a&gt;举报之，尽情选最高最反动的那档，然后坐等鱼儿上钩、苍蝇入罐。&lt;/p&gt;

&lt;h4&gt;数据和讨论&lt;/h4&gt;
&lt;p&gt;等的过程这里读者就不用体验了（高兴的读者可以自行体验）直接给出结果，就是&lt;a href="https://spreadsheets.google.com/pub?key=tVlHy3eLwYIvUFZSadsbc-A" title="这个时候使用hosts法是对的，因为google数据中心的ip太多"&gt;这个表格&lt;/a&gt;。这次钓鱼的一个很大失误就是忘记设置robots.txt，让搜索引擎的爬虫造成了大量噪音，给日志分析带来很大困难，这里展示的数据已经把搜索引擎直接产生的噪音去掉了，但是搜索引擎引来的访问者却很难办。&lt;/p&gt;

&lt;p&gt;我们来对数据进行一些分析。首先拿到IP要做一下whois，看看究竟who is it。这就有结果了，看whois那栏，一个是公安部的网监，一个是BAOSHAN-POLICE，呵呵，上海的。它们的其他各项header相似性很高，其中奇怪的是Accept-Language是en-us的，其他header也给得很少。难道我们机智的警警察察已经人人都考过英语四级了，用英语版Windows？显然不是，根据先验知识加以推测，这应该就是金盾网的内网出口。根据这一特征，又找到CHINANET-FJ和CHINANET-GD 的两个警警察察。注意到，在31日就有&lt;a href="http://twitter.com/Cattyhouse/status/3664668099" title="“卧槽，卧槽啊，co.cc被墙了…” 5:40 AM Aug 31st from dabr"&gt;报告&lt;/a&gt;说整个co.cc被封，9月1日的那位还能访问，这说明两件事情：1）警警察察枪决罪犯以后要验尸；2）警警察察上网没有墙。&lt;/p&gt;

&lt;p&gt;那个UNICOM-TJ的是怎么回事？我们来分析一下这个诱饵是怎么被咬掉的。我们建立的诱饵之一域名是shangwang.co.cc，然而最终被封掉的却是co.cc。我们来观察一下17日凌晨这位来自天津的朋友他的referrer是：&lt;code&gt;http://www.google.cn/search?q=gfw+co.cc+dns&amp;ie=utf-8&amp;oe=utf-8&amp;aq=t&amp;rls=org.mozilla:zh-CN:official&amp;client=firefox&lt;/code&gt;。就是说这位朋友通过在谷歌中文搜索“gfw co.cc dns”这个关键词找到了这个网站，为什么要这样搜索呢？为什么过了几天整个co.cc就被封了呢？这无疑是抓你一个，杀你全家的做法。结合当时的情况，net.ru在这之前被封掉，idv.tw在这之后被封掉，做法都是直接把cctld列为关键词，我们不难这样推测GFW的习惯：看见一个不熟悉的域名，先谷歌一下看你是不是属于大户人家，一搜发现哦原来net.ru和co.cc你们都是些免费的弃儿，就杀你全家，斩草又除根春风吹不生，反正没人知道。不过天津的那位又是谁呢？难不成是坐落在天津的公安部麾下“国家计算机病毒应急处理中心”？天津这位朋友后来居然还会从瑞士走代理来访问，而且我们设置的两个诱饵他都碰了，这确实非常先进了。&lt;/p&gt;

&lt;h4&gt;未来研究&lt;/h4&gt;
&lt;p&gt;这只是一次孤立的钓鱼，数据还是不具有普遍性，如果这样的实验成规模地重复，那么GFW的工作周期和口味都能有更清晰的了解。如果利用javascript甚至更侵入性的手段，还可收集到更多信息。另外一个直接的提示就是，网站管理者应该调查APNIC的whois数据库查出属于网监的IP段并“软性屏蔽”之，这样对于避免安全问题可以起到一定效果。一个需要考虑的问题是，如果以后GFW在先期侦察和验尸的时候都注意隐藏信息，调查访问者身份就会增加一些困难，但是如果搜索引擎隔离得足够好还是问题不大的。&lt;/p&gt;

&lt;h4&gt;结论&lt;/h4&gt;
&lt;p&gt;我们通过利用&lt;strong&gt;GFW在侦察目标时自认为置身暗处而不采取防护的漏洞&lt;/strong&gt;，进行了一次钓鱼实验并获取了适量数据进行分析，证实了&lt;strong&gt;net.china.cn举报平台与GFW在工作流程上的密切关系&lt;/strong&gt;，并发现了可能&lt;strong&gt;来自金盾网的举报验证&lt;/strong&gt;，以及证实了&lt;strong&gt;金盾网使用“防外线”不受GFW影响&lt;/strong&gt;的传言。我们还分析发现了&lt;strong&gt;一种GFW对于小站点的极端封锁策略&lt;/strong&gt;，以及&lt;strong&gt;一种封锁实施后验证封锁的行为方式&lt;/strong&gt;。不幸的是，这次钓鱼带来一个意想不到的后果就是co.cc全军覆没，对那些采用co.cc做域名的站长们在这里只好抱歉了。我们原来还试图生成一个de bruijn序列来高效证明著名的&lt;em&gt;法轮猜想&lt;/em&gt;——“任意其他GFW关键词的长度都大于"falun"”，没想到短短时间就又出现一个长度为5的新秀与老牌关键词falun并驾齐驱，真是出乎意料。&lt;/p&gt;

&lt;p&gt;总结这次实验，钓鱼的哲学有两条：一条是钓鱼比的是想象力，感兴趣的童鞋可以观赏Mitnick的&lt;cite&gt;The Art of Deception&lt;/cite&gt;会有更多收获；另外一条是，钓鱼需要耐心，这次钓鱼实验持续近半个月一无所获，“那是极端反动的大妓院啊怎么不快快封掉？！”我们几乎以为失败，鱼最终才上钩，如果没有比鱼更多的耐心是钓不到的。同理推之不难想象，上海的哪个闲得蛋疼人士也可以开着一辆破车去钓鱼，只要把一个对方的“钩子”钓到自己车上，之后想做什么那都好办了。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-3991579747292607369?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/3991579747292607369/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfw.html#comment-form' title='16 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/3991579747292607369'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/3991579747292607369'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/11/gfw.html' title='GFW钓鱼计划'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>16</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-8167075921654874810</id><published>2009-10-27T00:55:00.004-04:00</published><updated>2009-11-30T06:22:36.166-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Understanding GFW'/><title type='text'>深入理解GFW：总论</title><content type='html'>&lt;p&gt;GFW，Great Firewall of China，防火长城，通常把它看作一个国家级的网络审查系统。关于网络审查，人们通常首先会有一番政治性的话要说，不过政治批评这个角度的言论实在是过多，GFW的实体在“GFW”这个这个巨大的外壳之下隐藏了多年，人们只是对着“GFW”这个词空发怒气却并不知道它究竟是什么。实际上GFW除了是一个让网民十分不舒服的系统之外，在技术上它还是一个非常复杂有趣的黑箱，一个通关奖品是网络自由的解谜游戏。接下来一段时间我们便会对GFW进行深入的探索和理解，大家很快就会了解到它的趣味。提示：阅读此“深入理解GFW”系列之前建议读者对TCP/IP协议族、网络安全、反向工程有基本的了解。&lt;/p&gt;

&lt;a name='more'&gt;&lt;/a&gt;

&lt;h4&gt;GFW的技术结构&lt;/h4&gt;
&lt;p&gt;知己知彼，百战不殆，我们应该先对GFW有清晰的技术性认识。防火长城条目称GFW的主要技术是域名劫持、IP封锁、关键字过滤阻断、HTTPS证书过滤。实际上这些技术在实现上可以归结为两种技术：IP封锁和入侵检测，其中入侵检测是核心。IP封锁因为比较底层，接近于切光缆拔网线，没有什么技术可言，这种封锁实施以后除了绕道而过也没有更好的解决办法。而入侵检测则是GFW最为强大灵活的功能。&lt;/p&gt;

&lt;p&gt;传输层的TCP和UDP解析都是入侵检测业界的标准配置。UDP通常用来做DNS查询劫持，一个附加效果就是国内的域名缓存充满了麤。TCP主要用作阻断，方式很多了，总之只要把攻击者的连接关闭掉/阻止攻击者进行连接就行了。应用层就更加百花齐放了，因为解析一个协议实在不是一件困难的事情。所谓的SSL证书拦截也不过是稍微做了一下SSL/TLS协议的解析而已，并无神秘之处。这就是入侵检测的强大之处。&lt;/p&gt;

&lt;p&gt;入侵检测的灵活之处在于它的部署和撤销都很便捷无副作用无延迟，匹配精确无误伤。举一例，要防止一些反动软件通过https访问google docs获取信息，怎么做？在应用层检测证书显然是杀鸡用牛刀浪费性能了；用动态路由封特定IP的特定端口是不行的，因为解析结果在不断地变，动态路由的变化跟不上；用域名污染更不行了，把80端口的web业务也搞掉了，影响太大；所以就在传输层乱发RST做无状态的连接阻断，写个脚本定时更新解析结果，这也就是google的数据中心只有在中国解析出来的那部分被封掉的原因。什么时候领导对谷歌的红包满意了，随时撤掉。&lt;/p&gt;

&lt;p&gt;GFW的设备有两种，一种是在北京、上海、广州搭在总交换中心上做旁路监听的入侵检测设备，一种是放在ISP那里的动态路由设备。一般来说入侵检测总是比动态路由来得灵活，所以RST要比封IP更常用。另外，碰到网站无法访问然后traceroute发现线路死在ISP骨干上于是责怪ISP，这是不合理的。中国的ISP的一项主要业务就是接待各个强力部门的插入，纪检、军队、公安之类的部门都会长期插入。&lt;/p&gt;

&lt;h4&gt;GFW的工作方式&lt;/h4&gt;
&lt;p&gt;GFW的日常工作方式：当国新办发现了反动文宣，当公安部十一局发现了色情图片，当版署发现了海盗网站，总之当有关部门发现了有害非法信息，就发指令给GFW，然后GFW的政策部门研究一下采取怎样的具体封锁措施为宜，然后将具体操作交给技术部门执行封锁。解封也是一样的渠道，简而言之就是领导一句话胜过千军万马，至于让领导发这一句话靠的就是PR了。举一例，受到NED暗中操控的twitter长期以来充满反动有害信息，但做技术的人都明白twitter的这种架构是没有办法封的。对twitter.com什么办法都用了，效果不大好，结果领导不满意地催促了。这个交不了差是很严重的事情啊，怎么办呢，就对twitter搞破坏吧。凡是跟twitter有关的第三方网站，见一个斩一个，领导你看我都把twitter诛九族了，这已经是自古以来用刑的极致了。再举一例，如何封掉一个网站？先在这个网站上放置一些有害非法信息，再去违法和不良信息举报中心（后台国新办）举报之，等十天就成了。&lt;/p&gt;

&lt;p&gt;GFW的研发方式：“国家信息安全管理系统”建设的历史参见《阅后即焚》。当有关部门发现了一个反革命翻墙方法，就告诉GFW，然后GFW的逆向工程人才研究一下这个方法的工作方式，找到它的特定模式和弱点，制定相应的封锁预案。当有关部门指示实施封锁的时候，预案便付诸实施。p2p方面的反动软件比较不好办，于是在第一生产力院成立242项目“P2P协议分析与测量”专门研究之。&lt;/p&gt;

&lt;p&gt;GFW实体是&lt;a href="http://www.cert.org.cn" title="别想着把人家门户DDoS跨了就把墙推倒了"&gt;安管中心&lt;/a&gt;（CNCERT/CC），是事业单位。一个事业单位的政治地位可以想是很低的，凡是它的上级都可以向它下指令进行网络封锁，而它本身则没有任何主观能动性，专于业务，勤勤恳恳抓好国家安全基础设施的建设。如果转换角度，从GFW的视角来考虑，那么GFW所做的事情其实并不神秘，其实恰恰符合了它自己的名义。我们来看看精美的“&lt;a href="http://www.cert.org.cn/articles/researchProject/common/2006112023094.shtml"&gt;宽带网络环境下恶意代码监测系统&lt;/a&gt;”，你们这些反革命访问一下blogger、wordpress那就是URL攻击啊，而且要比一般的钓鱼攻击和病毒更严重，因为危害的是党和国家的安全啊。GFW的研发也与一般的网络安全公司所做别无二致，监视分析网络流量，逆向工程有害软件，阻断恶意攻击，区别只在于：GFW为了国家安全也要处理一下你们这些反革命的攻击；另外GFW还开了金钱无限、人口无限和无敌秘笈。&lt;/p&gt;

&lt;h4&gt;GFW与网民的生态系统&lt;/h4&gt;
&lt;p&gt;政府、GFW与网民构成了一个生态系统，政府与GFW共生于食物链的上端，网民处于食物链的下端。有人称之为“&lt;a href="http://momentago.cn/blog/2009/10/gfw-and-anti-gfw.html"&gt;猫和老鼠的游戏&lt;/a&gt;”。观GFW与网民的互动历史，可以归结为相互提升技术水准的军备竞赛，但尽管如此两者的关系也从来没有打破GFW越来越善于主动追捕网民越来越善于被动逃避的模式。从最开始的普通HTTP代理、SOCKS代理，到以自由门为代表的一批加密代理软件，到种类繁多的网页代理，到VPN、SSH代理，到p2p网络，以及混合方法。然而这些方法都未曾彻底免于GFW的封锁，这是因为GFW很善于进攻，而网民们迄今为止只会不断地四处寻找新的逃避办法。&lt;/p&gt;

&lt;p&gt;这种互动模式的问题在于，随着军备竞赛的继续，GFW越来越完善越来越强大，而网民不断地失去手中的牌，翻墙的难度和成本越来越高。GFW是这个领域（网络安全）的专业人士，而网民虽然富有群体智慧，但是其技术能力缺乏有效组织不能与GFW对等。因此如果稍微看得远一些就会了解到，这种模式对于网民来说是不可持续的，总有一天GFW会超过绝大多数网民的技术基准线。所以，唯一的出路便是改变方式，突破这种模式。&lt;/p&gt;

&lt;h4&gt;应对GFW&lt;/h4&gt;
&lt;p&gt;网民突破当前被动态势方法的基本原理，在后面的章节中我们会看到，在于利用GFW在善于进攻的同时不善于防守的特点。与其把GFW看作国家网络暴力机关，不如把GFW看作一个网络安全机构，事实上它也是一个网络安全机构（CNCERT/CC）。任何安全系统必然都有漏洞和弱点，它所提供的这个GFW安全解决方案（国家信息安全管理系统）也不例外。网民并非缺乏技术，而是技术没有得到有效组织，没有往这个方向进行有效投射。实际上GFW漏洞和弱点并不少，有一些甚至是理论上无法解决的，这在以后会详细论述。正如《阅后即焚》一文所言，GFW尽管是中国少有的顶尖科研力量与国家强力支持结合的产物，“但也无法摆脱山寨的本性——做一个东西出来很容易，但是要把这个东西做得细致严格就不行了”。&lt;/p&gt;

&lt;p&gt;更进一步，除了利用GFW本身的问题以外，网民甚至还可以考虑采取网络正当防卫的方式阻止GFW的非法行为。像GFW这种机构，无行政立法，无舆论监督，无申诉渠道，被少数别有用心的人利用，滥用国家安全之名义，封锁与国家安全毫无关系的网站，对合法的网络通信进行干扰和攻击，“对计算机信息系统正在进行传输的合法数据进行篡改，向计算机信息系统进行攻击令其无法正常运行”，甚至曾多次造成全国性网络故障，已触犯《中华人民共和国刑法》第二百八十六条，情节特别严重，后果特别恶劣，云云。&lt;/p&gt;

&lt;p&gt;然而另一方面，GFW与网民之间已经或者即将形成某种稳态，这种稳态是双方斗争状况下的动态平衡，是需要有意识维护的。一个无法控制的网络是无法被政府所容忍的，当网络无法控制时政府是不吝于切断一切网络的（你一定知道我在说什么），稳态的破坏也就意味着环境的毁灭。一个理想的稳态就是网络处于“看起来”可以控制的状态，让GFW处于不断取得小型封锁成功的虚幻胜利感之中，网民个人各自掌握非中心化的翻墙方法。一个中心化的大众翻墙方法（最典型的例子就是设置hosts静态解析）必定无法避免被当局发现并被GFW封锁。下一代的翻墙方法应该是去中心化的（p2p）、小众的、多样化的、混合型的、动态更新的。&lt;/p&gt;

&lt;h4&gt;参考文献&lt;/h4&gt;
&lt;p&gt;有两篇重要文献在这里要推荐。&lt;/p&gt;

&lt;p&gt;首先是Thomas Ptacek等在98年发表的&lt;cite&gt;Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection&lt;/cite&gt;。这篇是在入侵检测领域具有里程碑意义的论文，是论述入侵检测原理性漏洞的集大成者。其简明介绍早在07年就出现在英文维基，非专业人士可以&lt;a href="http://en.wikipedia.org/wiki /Intrusion_detection_system_evasion_techniques"&gt;一睹为快&lt;/a&gt;；专业人士建议仔细阅读原文，以后关于探索GFW漏洞的技术都基于此篇论文所描述的原理。&lt;/p&gt;

&lt;p&gt;另外一篇是《阅后即焚：“GFW”》，是一份关于GFW的详尽的社会调查，澄清了大量关于GFW的误解，本文大量引用此文。这篇文章的重要性从侧面可以发现：前面引用过中文维基的防火长城条目，如果直接访问会发现，这个条目直接访问之后维基百科就被封锁了。这是有原因的，而且原因是可以找到的，寻找原因的方法将在以后几节介绍，这里长话短说原因就是：这个页面中含有一个关键词：“阅后即焚”。与一般的关键词不同，这个关键词很厉害，随便什么地方出现这个关键词都会引起有趣的现象，比如&lt;a href="http://pastebin.ca/1640021"&gt;这里&lt;/a&gt;，这种现象通常被人们称为深度包检测。像法轮六四这样煽动颠覆的词语都没有成为深度检测关键词，这种顶级过滤的词很少，另一个例子就是GFW头号死敌的名字：“dongtaiwang.com”。一般来说，越是被禁止，就越有趣；越是被否认，就越接近真相。另外注意到，有一篇内容相似的文章《GFW的前世今生》，对比两者发现后者似乎被添加了一些不相关或者夸张性的文字，原文应该是首发在&lt;a href="http://freemorenews.com/2009/08/30/burn-after-reading-gfw/"&gt;自曲新闻&lt;/a&gt;的前者。&lt;/p&gt;

&lt;p&gt;在下一次的文章中我们将介绍GFW进行黑箱分析的方法，并得到一些有趣的结果。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update&lt;/strong&gt;：“阅后即焚”不再是全文关键词。&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-8167075921654874810?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/8167075921654874810/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/10/gfw.html#comment-form' title='12 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/8167075921654874810'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/8167075921654874810'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/10/gfw.html' title='深入理解GFW：总论'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>12</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7098741402030378580.post-3623355017605505165</id><published>2009-10-23T05:22:00.001-04:00</published><updated>2009-10-23T05:22:52.775-04:00</updated><title type='text'>Hello world.</title><content type='html'>first post&lt;br /&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7098741402030378580-3623355017605505165?l=gfwrev.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://gfwrev.blogspot.com/feeds/3623355017605505165/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://gfwrev.blogspot.com/2009/10/hello-world.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/3623355017605505165'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/7098741402030378580/posts/default/3623355017605505165'/><link rel='alternate' type='text/html' href='http://gfwrev.blogspot.com/2009/10/hello-world.html' title='Hello world.'/><author><name>gfwrev</name><uri>http://www.blogger.com/profile/16682741858221773431</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='29' src='http://1.bp.blogspot.com/_9r9_B-_Yw3w/SuF3jJpFU8I/AAAAAAAAABY/g1kOSL-4-cY/S220/t2.png'/></author><thr:total>0</thr:total></entry></feed>
