.CO域名快被这帮搞IT的玩坏了……

2014-06-14

.CO域名

鉴于近来国内访问Google的服务受阻,greatfire.org于前天推出了其基于亚马逊AWS的Google搜索镜像网站,地址是sinaapp.co。该网站随后因多家海外媒体的报道和众多微博大V的转发而一炮走红。我们不用想都知道,其结果必然是接受入侵检测装置的认证。不过比较狗血的是,新浪SAE旗下的sinaapp.com域名因为域名中也含有“sinaapp.co”字样,所以随同singaapp.co一同受到了“特殊照顾”——当从海外访问sinaapp.com域下的应用时,都会提示“连接被重置”。

虽然“认证”随着新浪方面的积极奔走而被取消,但这种使用知名网站类似域名的方法显然被玩坏了——greatfire.org的所有者随后注册了baidustatic.co(百度)、alicdn.co(阿里)、gtimg.co(腾讯)等国内知名网站的相似域名并指向其镜像网站。在V2EX上,有网友建议再注册几个诸如inhuanet.co、anqiu.com之类的域名;甚至有人YY,要是注册个chinamil.co域名然后被BLOCK掉,PLA会是什么反应。在我写这篇文章时,我发现chinamil.co确实已经指向过去了,不知后面会如何……

.CO域名之所以被众挨踢男玩坏了,完全是因为入侵检测装置在对用户访问的URL进行分析时,并不是仅仅提取出其中的HOST部分,而是对整个请求URL进行匹配。我们甚至可以发现,即使这些字符只是出现在请求参数部分,连接也一样会被阻断。

我一直在考虑一个问题(纯技术角度),为什么是对整个URL、而不仅仅是HOST部分进行匹配呢?从HTTP协议来讲,HOST部分和请求参数是分开的,单独对HOST部分进行匹配效率应该更高才对啊,为什么还要匹配请求参数呢?从我的个人经验来看,我觉得主要是两个原因吧:

第一、干掉那些把访问地址“明目张胆”地放到URL参数中的Web代理服务器。早期的Web代理服务器经常是直接把请求地址加入到URL参数中,比如经由Web代理访问http://www.a.com/index.html时,早期的Web代理请求的URL就是http://webproxy/www.a.com/index.html。显然,通过检测请求参数(”/www.a.com/index.html”)便能发现Web代理的真实意图,从而在请求连接阶段就把连接干掉。

第二、一些URL参数中是含有具体内容的,如果发现这些内容中含有敏感信息,便可以趁早采取下一步的措施,比如立即将”RESET标志位“置1重置连接。将连接在发起阶段干掉,便可以避免对连接建立后返回的数据再次进行深度检测,从而降低了负载。

PS:其实这种玩法我几年前就已经想到了,只不过没打算”擦边球“,所以只是想想罢了。


除非特殊说明,本博客文章均为原创,转载请以链接形式标明博文地址。

本文链接地址: .CO域名快被这帮搞IT的玩坏了……

分类:随笔文章 | 标签: |