不知道为什么,本来不受重视的L’Yun,却一直多灾多难,前几天空间呗停掉了,一个很以为的原因,每天将近9G的流量,晕死了,最多的一天才只有6个IP,但竟然有这么大的流量。后来查看了下日志,竟然是两首MP3引起的,每一秒钟都有人在下载。刚开始以为是百度干的,但是后来看了下在百度的位置,还不至于达到那么大的流量,然后自然而然的就想到迅雷了,看看别人的文章,可以肯定下,迅雷是个流氓!
解决方案:
1、对服务器的攻击屏蔽后,不用理会,不会造成太大影响。
2、被百度收录的是一部分MP3,因为不希望不访问网站就直接从后台下载网站的mp3,于是增加搜索引擎访问限制。在网站根目录下放置robots.txt,内容如下:
User-agent: Baiduspider
Disallow: /****
*表示不允许百度搜索引擎收录的路径。相对于百度,雅虎、MSN和Google的搜索引擎机器人没有那么流氓,所以不需要屏蔽。
3、对付迅雷。
相对于有些流氓的百度搜索引擎来说,迅雷就是恶霸了。
对于小网站站长来说,迅雷的分布式下载几乎是一种灾难。尽管迅雷给广大普通用户带来快捷方便,但给小服务器的负载带来严重灾难。
调用access日志,发现瞬间连接超过1000,而连接的集中点,居然是周董的一首《七里香》。尽管迅雷隐蔽的很好,但还是从日志的蛛丝马迹里找出它的影子。
于是先删掉七里香。删掉后仍有大量链接寻找其他MP3,而且删除一首mp3也只是治标不治本。启用Apache2的Rewrite模块。
在Apache的Http.conf中,开启Rewrite模块
LoadModule rewrite_module modules/mod_rewrite.so
然后增加以下Rewirte规则
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://www.cfobbs.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.cfobbs.com$ [NC]
RewriteRule .*\.(mp3|rm|wma)$ http://www.cfobbs.com/error.html [R,NC]
该规则表示,只有浏览器的REFERER是本站开头的连接,才可以下载MP3、rm、wma,否则转向error.html错误界面。
重启Apache后,用Flashget测试,无法下载mp3了,IE直接下载也会报错,但迅雷仍然可以下,百思不得其解,于是查阅迅雷官方资料,居然发现迅雷采用了一个十分流氓的手段:伪造下载地址的浏览器REFERER头,真是无耻。
考虑到网站的MP3全部是在网页自动播放,基本不需要额外下载,于是为了对付迅雷,采用了一个比较极端的方式:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !^NSPlayer.*
RewriteCond %{HTTP_USER_AGENT} !^windows.*
RewriteRule .*\.(mp3|rm|wma)$ http://www.cfobbs.com/error.html [R,NC]
也就是说,网站上mp3、rm、wma格式的文件,只允许播放器播放,不允许任何其它方式的访问,否则就转向错误页面。
重启Apache,使用迅雷下载,结果迅雷直接去下载了错误页面,初战告捷。
调用access日志,发现所有的mp3下载都提示302,转向了错误页面,而周董的七里香,则是404,直接报错。
自鸣得意一把。
顺便找到一个限速模块,对网站体积较大的文件进行限速,确保服务器稳定
LoadModule limitipconn_module modules/mod_limitipconn.so
BandwidthModule On
ForceBandWidthModule On
Bandwidth all 0
MinBandwidth all 0
LargeFileLimit *.mp3 500 50000
LargeFileLimit *.wma 500 50000
该模块可以指定文件名、文件大小限速,上面的意思是,MP3和WMA文件,凡是大小超过500K的,限速50K,大小不超过500K的,不予限速。
启用该模块,必须先行启用status模块
LoadModule status_module modules/mod_status.so
ExtendedStatus On
否则限速模块无效。
本文仅说明如何在服务器端屏蔽迅雷下载,包括HTTP方式和FTP方式,不涉及客户端和局域网内如何屏蔽迅雷的内容。
一旦服务器上的文件被迅雷索引,就会引来一大堆盗链的家伙,这对小带宽或低配置的服务器来说是致命的打击,于是如何限制迅雷下载服务器上的资源就成了一个很重要的问题。像我自己的服务器,用1MBps小水管来提供一个小网站的HTTP服务,开了内容压缩并设置好图片文件的缓存时间后,打开网页的速度还是比较快的,直到有一天,我发现网站打开的速度变得很慢,而且不是我自身的网络问题(当时我在外地,服务器在家里),当时仅仅知道是服务器上什么进程占用了大量带宽,还没有发现是迅雷的问题。后来经过了很多调查,才发现是迅雷在盗链,看访问日志里面一行行的大型文件下载记录,那真是触目惊心啊。
发现原因是迅雷盗链以后我就开始研究如何在服务器上屏蔽迅雷的下载。首先在HTTP协议上屏蔽迅雷是比较简单的,靠迅雷的用户代理(User Agent)就可以识别出迅雷了,但是在FTP协议上如何识别迅雷就比较棘手了。在好友的帮助下,最后我们终于发现一个在FTP协议上屏蔽迅雷的方法。在此之间和之后,我就写了IIS的反迅雷插件和Serv-U的反迅雷插件。
不过IIS和Serv-U只能在Windows平台上使用,这也是因为当时我的服务器还是Windows操作系统。其实Apache的mod_rewrite模块可以将用户代理作为重写条件,当时我也写了篇文章说明如何在Apache上屏蔽迅雷,但是在那之后还是有不少人发邮件问我如何在Apache上屏蔽迅雷。好吧,既然如此我就再写一篇文章来详细说明如何在Apache上屏蔽迅雷,顺便介绍libantixunlei,这是用于FTP反迅雷的一个C语言写的库。
上面是废话,欢迎忽略,下面进入正题。
在Apache上屏蔽迅雷
在HTTP协议上识别迅雷是通过迅雷的用户代理(User Agent)字串来进行识别的。我对我自己的网站的IIS访问日志以及一个评分系统的评分记录里面记录的用户字串进行了分析,之后发现迅雷使用的几个用户代理应该是唯一的,在访问日志中,除了下载文件的记录,只发现了极少量使用了和迅雷相同的用户代理的记录,这可能是个别用户出于杂七杂八的目使用迅雷下载普通网页而留下的日志。
有了这个分析结果,就可以保证通过用户代理来识别迅雷不会误杀普通用户了。但通过用户代理来识别迅雷有一个问题,如果以后迅雷把自己的用户代理改成和IE的用户代理一样的话怎么办?没关系,至少到现在为止(09年国庆),我还没有发现迅雷做此举动,等迅雷有动作了再想对策也不迟。另外,这里还有一个“脏数据”的方法,如果迅雷很不厚道地把自己伪装成IE的话,我们就只好也很不厚道地使用脏数据方法先反击一下迅雷。虽然脏数据对屏蔽迅雷没有什么帮助,至少可以出出气,让非最新版迅雷用户下载不到正确的内容,就这点应该够迅雷受的了,用户体验大受打击,我想大多数用户都不会追着使用最新版的。
于是,我在废话里面说了,使用Apache的mod_rewrite模块就可以很容易地屏蔽迅雷,因为这个模块的重写规则可以将用户代理作为判断条件。我们只要把用户代理和迅雷是一样的连接请求重定向到一个错误页面,或者干脆直接返回403,就可以在HTTP协议上屏蔽迅雷了。
到目前为止,我们观察到的迅雷使用的用户代理有以下几个:
- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )
- Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.0)
- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 3.5.20706)
- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
放心,根据网站访问日志和评分系统的日志,这些用户代理应该都是迅雷特有的,在.htaccess文件里面把带有这些用户代理的请求重定向到错误页面就可以了。
当然对于普通网页来说,是没有必要屏蔽迅雷的,所以我们只需要屏蔽访问大文件的请求就可以了,于是.htaccess里面的内容就像下面这样:
- RewriteEngine On
- #Anti Thunder
- RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.1\)$ [NC,OR]
- RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.0\)$ [NC,OR]
- RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.0\)$ [NC,OR]
- RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.1;\ \)$ [NC,OR]
- RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.0;\ \.NET\ CLR\ 3\.5\.20706\)$ [NC,OR]
- RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.1;\ SV1;\ \.NET\ CLR\ 1\.1\.4322;\ \.NET\ CLR\ 2\.0\.50727\)$ [NC]
- RewriteRule ^.*\.(gif|jpg|bmp|zip|rar|exe|mp3|swf)$ / [NC,F]
如果你想制定更复杂的重写规则,可以参考Apache手册中mod_rewrite的部分,见:http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_rewrite.html
对于其他Web服务器软件,多多少少都能提供一些可将用户代理作为判断条件的网址重写模块或插件,参照上面Apache的设置方法对这些软件进行设置,都能达到屏蔽迅雷的效果。
在FTP协议上反迅雷
在FTP上反迅雷就比较麻烦,这需要获得每一个FTP会话的会话唯一标识和客户端发送的每一条FTP指令。因为这样的需求很少见,所以Linux下的FTP软件很少有提供相应的接口供我们使用。不过还好,Linux下的FTP软件大多都是开源的,我们可以自己修改源码。于是我就写了libantixunlei,然后针对不同的FTP软件,就套用libantixunlei来修改其源码,然后编译安装就可以了。
因为要修改FTP服务器软件的源码,这对技术的要求就比较高了,不见得每个服务器管理员都会C语言,所以对大多数服务器管理员来说目前还是只能等待别人为FTP软件写插件(如果支持的话),或者发布经过修改的FTP服务器软件源码。
于是,如果你想为某个FTP软件加入反迅雷的功能,请访问http://code.google.com/p/libantixunlei 。如果对libantixunlei的用法不太清楚的话,请给我发邮件,我会告诉你FTP协议上屏蔽迅雷的原理和应该使用libantixunei的哪些接口来识别迅雷。
不过先不要失望,现在已经有了可以反迅雷的Linux上的FTP服务器软件了,在我写这篇文章的时候我已经给pure-ftpd 1.0.22版本成功地打上了反迅雷补丁,补丁文件请到:http://code.google.com/p/libantixunlei/downloads/list 去下载,下载回来以后给纯净的pure-ftpd-1.0.22版本打上这个补丁(使用patch命令),然后编译安装就支持反迅雷了。对于其他版本的pure-ftpd我没有试验过是否能使用这个补丁,不知道能否正常使用。另外在此提醒一下没有自己编译安装过软件的管理员,pureftpd的一些功能需要在./configure的时候加上一些参数才能使用,具体请看源码根目录下面的说明文件,偷懒的话可以 ./configure –with-everything,不过印象中官方并不推荐使用这个参数。
另外,因为我很懒,所以把一些特性写死在程序里面了,是否屏蔽使用迅雷的IP和屏蔽IP的时间是写死在程序里面的,要改变的话只能重新编译。这两个配置在libantixunlei.h文件里面可以修改。
libantixunlei使用了pthread库,而在一些平台上编译的时候如果要使用pthread库需要显式指定-lpthread参数,我在PBS服务器上编译的时候没有问题,但是在自家的一台电脑上编译的时候却出错了。如果编译失败的话,点击这个地址查看处理方法:http://code.google.com/p/libantixunlei/wiki/BianYiShiBai
将迅雷拒之门外 by 桔子小窝 is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.