是否存在对GFW实施直接攻击的可能性？

关于墙的技术讨论 看到一篇关于墙的技术讨论，作者似乎是在Redmond的同仁： —————————————————————————————————— 看来最近射击墙的理论已经几乎要进入实战了. 1. 今天周曙光在博客上写了对53端口的UDP 攻击可以实现. 相信不少人看到了. 2. 几星期前, 译言的一篇关于墙的工作原理的论文得到翻译, 也讲了对墙的 DDoS 方法 3. 一个多月前, 我在一个讨论组也发了类似的信, 可以借助在国外访问国内网址并且加入穿墙词攻击墙. 看来, 对于墙发动分布式攻击的时机和理论慢慢成熟了,但是现在没有人去做这个事情. 在此, 我提几个大纲性质的东西, 供大家参考: 1. 墙的计算能力是不可测的. 墙后面会异步的挂机群, 随时计算. 因此, 大计算量暂时打不倒墙. 墙也不会才去OCR搞图片或者反解简单加密的内容. 2. 墙的存储能力是极其有限的. 为了保证包匹配的快速, 墙必然在路由层面建立了匹配表. 匹配表的快速查找的需求决定了墙不可能有很大的存储空间(O(logN) 甚至 O(N) 查找时间). 而墙的设计漏洞在于, 一个记录必须在存储器里面保留5分钟.因此, 只要发动分布式射击, 墙必然会被包头塞满. 只要做到这一步, 墙就等于无用了. 3. 墙是点对点的. 所以, 单点射击不影响其他人使用. 在国内对国外放散弹或者在国外往国内放散弹都可以塞满墙的查找表. 4. HTTP 协议也可以用来打墙. 嵌在 IFrame 中的连接请求加上一个精心设计的 URL参数, 即可在墙上留一个枪眼五分钟. 无需任何资源. 无需对方配合. 这个为开发分布式提供了极大便利. 因为浏览器就是武器. 同时, 鉴于没技术人员发起, 我暂时充当一下发起者. 有兴趣的开源开发者请踊跃参加, 争取拿金牌. 了解网络协议者优先, 会写 widget 或者 SNS App者优先. 有意者留言. 或许下一届奥运会射击金牌, 就是你的! 我真心的希望, 我们这一代人, 经过几年努力, 能拿到这个金牌. 毛主席说, 既要能绕开, 也要能主动攻击, 兵法即如此. —————————————————————————————— 但是所谓道高一尺魔高一丈，作为扩展的国家机器的墙的威力（计算能力）还是不容忽视的。 yiyan的这篇文章http://www.yeeyan.com/articles/view/40085/11992非常不错，很值得学习。在这篇文章的基础上做了几个简单的实验，发现目前的墙的算法还是很愚蠢的： 1. 墙把url中的违禁pattern作为判断的重要依据，这样的好处是比较轻量级，比判断传送的网页的内容是否含有违禁pattern要轻量太多了，但带来的问题就是非常容易欺骗。例如www.sohu.com是什么会的官方站点，当然是根红苗正的，但是我可以在其访问的url上任意添加query string, e.g. http://www.sohu.com/?falun, 于是墙傻乎乎上当了，sohu在我这里就屏蔽了数分钟。 由于我在墙外，所以我拿墙内的网站试验，在墙内的可以拿墙外的试验，例如可以尝试： http://whitehouse.gov/?falun , 看看，白宫立刻被墙挥刀斩于马下。 ————————————以下内容作废———————— 2. 墙在url上另外一个设计局限是，显然墙把整个url path(query string以前的部分）作为了封锁的键，而不是把整个域或IP地址（ip同样有问题，因为可能对应很多ip地址）。带来的问题是，对于一些通配域名（大多数blog提供商都采用通配域名），这有几乎是无限多的组合，那么一个站点就可以在墙的禁止表中产生无限多的记录，这为DDoS攻击提供了非常好的温床，一个简简单单的javascript代码就能成为墙的噩梦。 例如， sohu的blog服务是采用通配域名的，我们可以随意输入任何域名: 1.blog.sohu.com, 2.blog.sohu.com, ... 都将解析成为一个有效的主机，实验表明，对1.blog.sohu.com采用一个含违禁词的query string, 导致1.blog.sohu.com被禁，而2.blog.sohu.com仍然有效。 基于此原理采用<img src="https://1984bbs.org/wp-content/themes/zibll/img/thumbnail.svg" data-src="http://site/?pattern" />就可以产生相同的效果。这就是说一个几行字的javascript可以轻松在不影响用户浏览，甚至用户不知情的情况下在墙上贡献n多个记录。如果这样的代码被放在有众多受众的web上，那么墙可能面临前所未有的冲击。墙是否能因此而崩溃是不得而知的，因为对付这种类型的DDos并非困难。处于众所周知的原因，测试代码不在这里公布了，但稍有javascript知识的朋友就知道这太容易了。 ——————————————以上内容作废————————————— Updated: 墙还是比想象要聪明一些: - 试验表明当同一个域名下的url撞墙次数过多后，所有此域名下的url都会撞墙，因此上述简单地用通配域名应该是不行的。 看来很可能还是通过IP地址来进行封锁的而并非url. 刚才手工试验的时候只是尝试了1，2，a,b几个子域名，而*.blog.sohu.com有多个IP地址轮流服务的，因此刚才试验很可能是恰好轮流到一个没有被封的ip了。 - 对这种情况下url撞墙封锁的时间貌似很短，只有1分钟到几十秒 再次Update: 考虑了一下，既然墙封锁的是ip而不是url中的host, 也不需要那么麻烦，采用javascript随机（或者在一定范围内随机）产生IP地址的办法是很简单的. 这样的副作用是，也许不小心就把你需要的IP也给墙了，在网页上放这样的代码可能造成用户体验的不佳。对于产生的无效地址是无所谓的，无效的地址和被墙掉的地址区别不大。 我的实验代码采用setTimeout() 和 <img src="https://1984bbs.org/wp-content/themes/zibll/img/thumbnail.svg" data-src= />,每500ms更换一个新的地址，根本不关心request发出去后怎么样，试验表明无效地址对浏览器端不构成什么影响。 -- 俺的实验结果设想： 既然墙临时封锁的策略是（IP dest, IP src）的匹配, 查找是不需要O(n)或O(log(n)) 而应该是线性的，且所占也空间很小，即使是人海战术，由于墙的计算能力、memory空间都可能是规模巨大的，因此这种ddos很可能不行。