覃伟帆博客 » 网络

威瑞信向ICANN申请执法权以响应域名被恶意使用

kuiGG — Wed, 12 Oct 2011 08:54:13 +0000

外媒报道，全球互联网专业域名服务提供商威瑞信（Verisign，纳斯达克代码： VRSN）于10月10日向ICANN（互联网名称与数字地址分配机构）提交申请，请求批准其新的反滥用域名政策。这个新政策如果获得ICANN批准，威瑞信将被允许对其提供服务的后缀（.com， .net和.name等）域名进行扫描，以检测恶意网站或钓鱼网站，扫描以季度的形式实行。如果该域名被认定为恶意使用，威瑞信将会对域名进行移除或锁定。

这个政策旨在赋权威瑞信采取迅速行动，终止其所掌管的域名之恶意使用。

至于域名持有人关注的正常使用域名被不当移除的问题，威瑞信表示将提供申诉渠道以恢复原有域名。

淘宝群雄起义带头大哥何在

kuiGG — Wed, 12 Oct 2011 02:54:27 +0000

昨天晚上，韩都衣舍赵总发出一条微博：刚刚接到一条信息：赵总，十万火急通报。有几个群要打一些淘宝大店的主意，其中包括你们家。就是因为这次商城改革，据目前知道的规模有几千人，他们决定整死一批商城的大店。现在赶紧赶回办公室，发现他们的行动果然已经开始了，立即召集有关负责人开会，商量对策。

配图中显示，起义军攻击商城卖家的手段是：1000人同时拍下一个店的同一件商品，拍完他就要发货，要是不发就全部申请赔偿，按照淘宝规则，72小时不发货是可以获得赔偿的，然后这个店就会被扣分扣到关门。如果全部发货，那么1000个人全部确定收货，全部给0分，马上把它的评分拉到最低值，没人再敢去买这个店的东西。这还不够，还要1000个人同时申请退款，按照淘宝商城规则，7天内是可以无理由退款的，然后该店单品的退款率马上到了100%，自然也不会有人敢买。

此微博一发，在江湖上引发了热议，对韩都衣舍等大卖家幸灾乐祸者有之，对淘宝商城新政慷慨激昂者有之，唯恐天下不乱者有之，仿佛一场腥风血雨即将到来，其真实全不亚于当年的反百度。

据悉，这场暴乱的导火索就是淘宝在双十节宣布提高对商城卖家的收费，将原有的每年6000元的技术服务年费提高至3万元和6万元两个档次，最高提升幅度达到原来的10倍。此外还将升级商家管理体系，建立“商家违约责任保证金”制度，商家进驻淘宝商城需要缴纳最低1万，最高15万的保证金。商家一旦有达到一定程度的违约行为，将扣除至少1万元的保证金。

其根本在于马云和阿里的理念转变，希望打造一个小而全的C2C、大而精的B2C，而如今的淘宝商城进驻的卖家过多，质量良莠不齐，显然达不到其预期的“精”,所以他们希望通过提高资金等各方面门槛的方式，驱逐商城中实力较弱的中小卖家。此举被称为过河拆桥，兔死狗烹，淘宝商城在过去一年内迅速发展，离不开商城中大量中小卖家的支持，有的甚至是割肉支持，跳楼支持，卖妻支持，而如今淘宝却要打小扶大，劫贫济富，不得不令他们委屈、愤怒。

起义爆发之后，韩都衣舍等大卖家纷纷将商城中的货品迅速下架，以消极方式应对攻击。而阿里巴巴向来强势，加之此次事关战略转型，回应“不会因为恐吓而放弃原则”，而且宣布“已经报警”。不过我不知道，报警能干啥，难道对这几千人跨省抓捕么，抓捕了又以什么罪名惩处他们？

据悉，此次起义组织起来的人数多达6000-7000，且分工明确，组织严密，整个群体分为30多个执行小组，每个小组有一两个人作为总监，负责策划和主持活动，分别针对不同的淘宝商城大店发起攻击。

照理说，组织这么几千个人起来同时起义，绝非易事，纵然中小卖家有愤怒有委屈，但是能一下子凝聚成这么大的力量吗？

所以我隐隐觉得，此次起义背后一定有一个“带头大哥”。

在新浪微博搜索“淘宝”，除了淘宝之外，出现得最多的是什么，是“品聚”、“葛斌斌”啊亲！再去品聚官方和葛斌斌同学的微博看看，出现得最多是什么，是“淘宝”啊亲！

而且葛斌斌同学在11号下午就宣布要卖坦克！坦克啊！不是模型！坦克是干啥用的，是起义用的，是打仗用的。

葛斌斌此人向来善于吹牛，当初出来搞电商，就搞了个概念“快乐电商”，还宣布“一年与淘宝平分天下，两年打趴淘宝，三年上市”，然后起个不知所云的奇怪名字“蛛族途”，放一幅明显针对淘宝的宣传图，被大家嘲笑起的名字垃圾，用的域名垃圾以后，用iPad作为奖励，到处征名，最后定为“品聚”。

最近品聚准备上线，上来上去现在就是一个跟团购差不多的玩意，最近又炒作卖坦克，很难说这次淘宝起义不是葛同学在作为“带头大哥”策划。

下载权限控制机制

kuiGG — Fri, 06 Aug 2010 08:16:29 +0000

要对下载的权限进行精确的控制（防止盗链，防止迅雷吸血，下载扣除积分等虚拟货币），以前接触的方法有几种：
1、通过rewrite不断地更改下载文件的url，并插入很多无意义的字符；
2、验证下载链接的来路，或者cookie；
3、通过服务器端程序（例如一个php文件），open文件，读取内容然后返回给客户端。

第一种方法很笨，而且吃力不讨好；
第二种方法很容易破解，因为referer和cookie都是客户端发出的，能够方便地伪造，而且迅雷对此已经是轻车熟路；
第三种方法是可行的有效的，所有的文件都经过一个程序读取并发送，在读取之前可以有效的验证权限，但是下载过程中始终要占用一个cgi线程，而且一般cgi语言的IO性能都不好，速度很慢，占用了服务器的大量资源，导致总体效率极其低下，难以大规模运用。

为此我研究了一下csdn下载频道的实现机制。
csdn下载频道能够有效的验证权限，扣除积分，而且不排斥迅雷等下载客户端，同一个用户下载同一个文件也不会重复扣除积分，而且下载时始终没有暴露文件的真实地址，同一个下载URL到了别的地方也完全不可用，可以说是实现得比较理想的。

我选择了一个文件进行测试，下载的url是： http://dldx.csdn.net/fd.php?i=573624740728082&s=4fc2353ca769a0ebd9237b6f98791679

这个url向文件存储服务器上的fd.php文件发送了两个经过加密的参数，里面应该包含有用户登录信息（用户ID和sid）和目标文件的ID号。
用迅雷下载这个文件，截获返回的头信息：
Host: dldx.csdn.net
Pragma: no-cache
Range: bytes=0-
Referer: http://d.download.csdn.net/down/2474072/waf9898
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )
HTTP/1.1 206 Partial Content
Server: nginx/0.7.65
Date: Tue, 22 Jun 2010 07:08:21 GMT
Content-Type: “application/octet-stream; charset=utf-8″
Content-Length: 667747
Last-Modified: Mon, 21 Jun 2010 23:45:02 GMT
Connection: keep-alive
Content-Disposition: attachment; filename=”DNF%E6%82%A0%E6%82%A05%5B1%5D.7.rar”
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Content-Range: bytes 0-667746/667747

这里面始终没有暴露目标文件的真实路径，不是一般下载系统所使用的header重定向的方式。而且有一个重命名的信号。服务器使用的程序是nginx/0.7.65。
根据这些信息，在google搜索到这篇文章：http://kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/
显然，csdn就是使用了文中所说的nginx X-Accel-Redirect。

解释一下整个过程：

步骤1，客户端请求http://dldx.csdn.net/fd.php ，并传递相关信息；

步骤2，fd.php根据所传递的信息判断出访问者的身份和所请求的资源，然后应该验证了客户端的IP，进一步判断其权限。如果这个客户端有权下载此文件，则在HTTP header加入X-Accel-Redirect: （文件的真实路径），并加上head Content-Type和Content-Disposition:；

步骤3，nginx得到fd.php的回应后发现带有X-Accel-Redirect的header，那么根据这个头记录的路径信息打开目标文件；

步骤4，nginx把打开文件的内容返回给客户端。

这样所有的权限检查和积分扣除等操作都可以在步骤2内完成，而且fd.php返回带X-Accel-Redirect的头后，其执行已经终止，剩下的传输文件的工作由nginx 来接管，同时X-Accel-Redirect头的信息被nginx删除，不会返回给客户端，也就不会暴露（实际上可以把目标文件存储在不能经由web访问的目录），并且由于nginx在打开静态文件上使用了 sendfile()，其IO效率非常高，比php的IO要快上N++倍。

这是一种优雅，有效，高效的实现方案。

因为没有架设过nginx服务器，我希望能在apache实现这个功能，于是查找了一下有没有类似的mod，果然查找到了一个mod_xsendfile：http://tn123.ath.cx/mod_xsendfile/ ，其实现机制与nginx的X-Accel-Redirect基本相同。

下载之后在本机测试。

1、加载mod_xsendfile。将文件 mod_xsendfile.so 移动到 apache/modules 目录下，将以下内容添加到httpd.conf中
LoadModule xsendfile_module modules/mod_xsendfile.so
XSendFile On
XSendFileAllowAbove On

2、使用PHP调用X-sendfile。代码如下：
接收_GET数据并解密；
验证uid、sid、文件id；
如果通过验证：
｛
扣除积分、计数统计等操作；
header('Content-Type:(目标文件类型)');
header('Content-Disposition: attachment; filename="(希望客户下载到的文件名)"');
header('X-Sendfile:(目标文件真实路径，使用绝对路径，例如"E:/www/dl/test.rar'，此路径可以是web无法访问的目录")');
exit;
｝
如果不通过：
｛
给客户端返回一个提示性的html文件；
｝

3、构造下载url，用迅雷成功下载；破坏验证条件（比如改变客户端IP）之后，迅雷只能下载到提示错误的文件。

实际应用中可以采用以下具体方案：
1、把所有的目标文件都存储在服务器B，此服务器不需要数据库，而且通过web只能访问到某入口文件（比如http://dldx.csdn.net/fd.php），在这个文件中配合apache实现X-Sendfile；
2、网站文件（php和html），以及数据库运行在服务器A（当然数据库也可以另设服务器），此服务器负责构造类似于 http://dldx.csdn.net/fd.php?i=573624740728082&s=4fc2353ca769a0ebd9237b6f98791679 的url；
3、服务器B接到以上URL以后，分析客户端IP，然后远程连接服务器A的数据库，把uid，sid，文件id，客户端IP进行匹配分析，通过则扣除积分放行下载，否则提示错误。

此方案最终就能够实现以下目的：
1、任何方式都无法直接通过web访问到目标文件，迅雷也没有办法；
2、类似于http://dldx.csdn.net/fd.php?i=573624740728082&s=4fc2353ca769a0ebd9237b6f98791679 的URL没有通用性，只能特定的用户在特定的IP访问特定的文件，迅雷即使把这个URL存储起来，也是没有办法吸血的（只能下载到提示错误的文件）；
3、文件存储和数据库两台服务器干净的分割，便于维护；
4、速度和效果都很完美，不会产生验证差错，也不会过多占用服务器资源。

中等规模相册的上传存储机制初探

kuiGG — Mon, 02 Aug 2010 03:15:18 +0000

这里对中等的定义是：图片文件所占空间在1TB–99TB。

这个机制是研究了人人网等一些UGC网站所得出的方案。

以4台服务器为模型：相册所属的主站服务器A、主站所用的Mysql服务器M、接收并处理上传文件的服务器B、最终存储图片文件并提供http下载的服务器C。实际应用中C应为多台服务器分布式存储。

首先，上传图片的入口在A上。那么，上传表单所属的html文件应该存储在A还是B呢？第一感觉应该是在A上，然后表单的action指向B，这样就可以直接把文件数据提交到B。但是事实上，我们通常会在相册中使用ajax提交表单，如果表单在A上，而数据提交到B，就会造成跨域的问题。所以，我们把这个表单部署在B上，通过同一个根域的cookie和存储在M上的session数据来验证用户身份。

B的基本任务是：验证，去重，处理，存储。

验证：B接收到数据以后，先判断文件大小和Content-Type、扩展名等是否符合要求。

去重：去重基本被大多数人忽略，我想是因为对很多网站来说短期内可以承受，但是实际的经验是，重复图片会占到50%以上的惊人比例，一些流行的图片会被不断地上传。而且这里还关系到一个审核的问题，比如一些流行的黄图或者不和谐的政治图片会被频繁上传，如果没有去重机制，会加大审核的工作量。所以，有必要对上传的每个文件取得一个二进制的MD5值，存储到数据库里。这里存入的不是M上的数据库，而是B自带的数据库。上传来的文件，如果MD5重复，就直接返回已经存在的图片路径；如果不重复，就插入新的数据，返回新的路径；如果该图片已经被判定违规，就返回一个错误信号。

处理：生成缩略图，可能是不同分辨率的缩略图。如果有需要，还得添加水印。

存储：存储分三部分：M上的数据库有相册图片相关的信息需要存入；B上的数据库也有文件信息需要存入；最后还得把文件存到C上，才能提供http下载。第一第二步不再叙述，第三步初步决定使用ftp（直接把上传的流写入ftp，B、C通信速度应该很快），也可使用专门的分布式存储系统来实现。路径可设计为 http://域名/分布式目录/20100730（年月日）/1355（时分）/large（不同大小）_（随机码）.jpg，把这个路径分解以后存储到M即可。

wordpress中默认的发邮件用户和地址的修改方法

kuiGG — Wed, 09 Jun 2010 00:03:43 +0000

wordpress中默认的发邮件用户和地址是 WordPress

我想把它修改成 kuiGG

研究了一下，找到修改的方法：

需要修改的文件是 wp-includes\pluggable.php

搜索“wordpress@” 有两处都改成 “i@”

还有找到以下代码

if ( !isset( $from_name ) ) {
  $from_name = 'WordPress';
 }

修改成

if ( !isset( $from_name ) ) {
  $from_name = 'kuiGG';
 }

浅谈验证码的识别技术

kuiGG — Sun, 26 Oct 2008 15:56:22 +0000

这些天出于一些需要，要求做程序识别某网站的验证码，于是潜心研究了一番，颇有心得，特此分享。

验证码识别这项工作不适合浮躁的人，它需要足够的技术和耐心。由于此技术的特殊性，任何一个被公开识别技术的验证码都会很快地失效，相关网站都会很快地更换验证码。所以本文只介绍最简单的验证码的识别和识别原理。

—————————

首先我选择一个最简单的验证码，找来找去，就选挑战网的评论验证码作为例子吧。随便打开挑战网一篇文章，找到发表评论处的验证码，查看其属性，获得其生成地址“ http://tiaozhan.com/checkcode.php ”。

显然，这是最简单的一类验证码：有固定的背景颜色，字符颜色，字体，连字符的坐标都是固定的。对于这类验证码，我们只需要对每个数字进行采样，建立标准库，然后应用的时候一一对照标准库，就可以轻易做到100%识别。

使用ImageCreateFromPNG函数把图片取回来，然后用imagecolorat函数取得每一个坐标点的色值，并且把第一个点的颜色确定为背景色。然后按照图像大小比例画一个表格，如果该单元对应的坐标颜色与背景色相同，不显示任何内容；反之显示黑色块。于是我们得到这样的分解图:

可以观察到，数字所占区域的y坐标是6-15，四个数字所占区域的x坐标分别为3-10，12-19，21-28，30-37。

于是建立以0-9为样本建立10个二维数组（$arr_eg[0] – $arr_eg[9]），该数组每一个元素均对应该数字区域的每一个坐标，如果该坐标色值与背景相同，值为0，反之为1 。这就是我们的标准库。

识别的时候，同样取得四个数组，与标准数组一一对照，就可以精确地把四个数字识别出来。

同时附上此验证码识别程序，供大家研究。（demo.php是程序；arr.php是标准库）

附件: secode.rar (1688 字节)
———————–

以上的例子虽然简单，但是已经把基本原理介绍清楚了，就是采样->建立标准库->应用->对照标准库->识别。

但是，实际应用中，遇到的往往不是如此简单的情况。比如下面是稍微复杂的一类验证码，它的背景和字符都不是纯色，还有很多干扰点，但其字符的坐标都是固定的。

首先我们对其进行去噪处理。就是首先把每个字符区域分割出来，按照出现的频率确定其主色值（字符的色值），然后去除与其相差大于一定程度的坐标，过滤之后得到目标所在的坐标数组，然后同样与标准库对照。但是这种情况下是不会精确吻合的，我们只能选择吻合度最高的昨作为结果。经过实践，识别率可以达到99%。

再难一点的，就是下面这种：使用了变色、干扰点、干扰线、变位等几种用于干扰手段。

与上一种不同，它的每一个字符所在的位置是不确定的，这就需要我们自己去确定其位置，把字符所占据的大小固定的那一个小块切出来。首先把所有的干扰点和干扰线去掉（去掉之后字符是有所“误伤”的，通常会缺1-3个像素点），得到比较干净的图，然后用一条横向和竖线去扫描它（比较形象的说法，具体如何实现请自己思考），把扫到的没有出现颜色的横竖线全部去掉，把分析范围缩到一个较小区域。然后再用竖线扫描，根据颜色的出现与否，又得到5个小区域，每个小区域再用横线扫，除去空白，得到目标区域。得到的目标区域有时候会比标准区域小想办法补全，然后对照，按吻合率最高的原则得出结果。最后识别率达90%以上。

再难一点。就是目前我研究的最难的一种了。如图，这种验证码除了干扰背景之外，每个字符的位置，大小，甚至字体都是不确定的。还好每个字符之间没有粘连。没有粘连就比较容易切字（当然要比上面那种难），切字之后字块大小不确定，所以很难建立标准库。我能想到的只有这样处理：切字之后对字块用横线或竖线扫描，根据其色块的坐标变化规律确定结果。目前正在实验中，能识别的字符还不完全，识别率也不甚理想。

———————

验证码识别这个问题算是人工智能和计算机视觉领域的一个难题。作为破解者，总是会处于劣势地位，而且此技术带有一定的不正当性，没有太多的研究交流，因此要做得很好，是非常困难的。而且个人对于很多OCR的技术，理解有限得很，不敢在此乱写，只能利用有限的知识，抛砖引玉而已。

KuiGG 2008-10-26
QQ 727136
E-mail i@kuigg.com

Happy birthday to Google

kuiGG — Thu, 27 Sep 2007 10:41:18 +0000

刚刚才发现Google的logo换了，还不明白是因为什么，看了一下logo的路径文件名（http://www.google.cn/logos/9th_birthday.gif），才知道是Google在庆祝自己生日。

小凡敬贺Google九年大寿，望多多发钱才是，哈哈。

iis命令行

kuiGG — Fri, 07 Sep 2007 14:51:37 +0000

Microsoft在安装IIS的时候同时安装了一个工具，叫 iisreset,你可以在winnt\system32 中找到它，他可以和PING一样以命令行方式使用。它有多个参数，下面是几个重要的，也是我们本文切题的参数：

/RESTART 停止后启动IIS
/START 启动IIS (如果停止)
/STOP 停止IIS (如果启动)
/REBOOT 重启电脑
/REBOOTONERROR 如果停止IIS失败重启电脑
/NOFORCE 不用强迫IIS停止
/TIMEOUT:X 在X秒后, IIS被强制停止,除非 /NOFORCE 参数给出.如果 /REBOOTONERROR 给出, 它重启电脑.

昨夜百度大更新，我的破博客两个词成绩不错

kuiGG — Fri, 24 Aug 2007 08:17:04 +0000

两个主关键词：

小凡第5 http://www.baidu.com/s?ie=gb2312&bs=pda&sr=&z=&cl=3&f=8&wd=%D0%A1%B7%B2&ct=0

小葵第1 http://www.baidu.com/s?ie=gb2312&bs=%D0%A1%B7%B2&sr=&z=&cl=3&f=8&wd=%D0%A1%BF%FB&ct=0

百度指数：

今天扔了几颗炸弹，希望“小凡”能排到第一…………

都是做着玩的，呵呵。

windows2003修改3389端口的方法

kuiGG — Sat, 04 Aug 2007 12:05:59 +0000

1、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\Tds\tcp下的PortNumber=3389改为自宝义的端口号
2、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp下的PortNumber=3389改为自宝义的端口号

这样就可以关闭3389端口，避免被扫描到

APACHE2如何里一个站点绑定多个域名？用ServerAlias

kuiGG — Sat, 04 Aug 2007 11:38:13 +0000

以前很笨，要使多个域名指向同一站点总是这样写：

ServerAdmin i@kuigg.com DocumentRoot /www/kuigg.com ServerName kuigg.com

ServerAdmin i@kuigg.com DocumentRoot /www/kuigg.com ServerName www.kuigg.com

ServerAdmin i@kuigg.com DocumentRoot /www/kuigg.com ServerName abc.kuigg.com
这样一来就等于绑了多少域名就开了多少虚拟主机………… 后来看了看书，发现有个叫”ServerAlias“的东西可以用其实可以这样：
ServerAdmin i@kuigg.com DocumentRoot /www/kuigg.com ServerName kuigg.com ServerAlias www.kuigg.com abc.kuigg.com
要绑多少个域名都可以写在 ServerAlias 后面，用空格隔开即可

301重定向的实现方法

kuiGG — Wed, 04 Jul 2007 15:49:10 +0000

页面永久性移走（301重定向）是一种非常重要的“自动转向”技术。

　　301重定向可促进搜索引擎优化效果

　　从搜索引擎优化角度出发，301重定向是网址重定向最为可行的一种办法。当网站的域名发生变更后，搜索引擎只对新网址进行索引，同时又会把旧地址下原有的外部链接如数转移到新地址下，从而不会让网站的排名因为网址变更而收到丝毫影响。同样，在使用301永久性重定向命令让多个域名指向网站主域时，亦不会对网站的排名产生任何负面影响。

　　302重定向可影响搜索引擎优化效果

　　迄今为止，能够对302重定向具备优异处理能力的只有Google。也就是说，在网站使用302重定向命令将其它域名指向主域时，只有Google会把其它域名的链接成绩计入主域，而其它搜索引擎只会把链接成绩向多个域名分摊，从而削弱主站的链接总量。既然作为网站排名关键因素之一的外链数量受到了影响，网站排名降低也是很自然的事情了。

　　综上所述，在众多重定向技术中，301永久性重定向是最为安全的一种途径，也是极为理想的一款解决方案。

　　对于正确实施301重定向，有这样几个方法可供大家参考：

　　1.在.htaccess文件中增加301重定向指令

　　采用“mod_rewrite”技术，形如：

RewriteEngine on
RewriteRule ^(.*)$ http://www.kuigg.com/$1 [R=301,L]

　　2.适用于使用Unix网络服务器的用户

　　通过此指令通知搜索引擎的spider你的站点文件不在此地址下。这是较为常用的办法。

　　形如：Redirect 301 / http://www.kuigg.com/

　　3.在服务器软件的系统管理员配置区完成301重定向

　　适用于使用Window网络服务器的用户

　　4.绑定/本地DNS

　　如果具有对本地DNS记录进行编辑修改的权限，则只要添加一个记录就可以解决此问题。若无此权限，则可要求网站托管服务商对DNS服务器进行相应设置。