spam

随着web services使用范围的越来越广，这种类似于trackback的远程xml-rpc调用技术将越来越普及，伴随而来的是大量的spam。blog的 trackback spam不同于comment spam，comment spam是个技术单一，效率比较低的spam机制，很多blog系统在接受comment表单提交时会判断页面来源，如果页面地址不是合法url将会拒绝，trackback不同，trackback可以基于任何一台联网的机器向全世界任何的blog系统发送cgi命令，所以对付trackback spam的方式不同于comment spam，下面我将简单讲述一下我认为可行的一套anti-spam方法。 脆弱的暴露TrackBack Url太危险了！第一步，必须隐藏URL 拿donews的blog来说,它的默认日志页面是如下 日志页面URL：http://www.donews.net/$USERNAME/archive/$YYYY/$MM/$DD/$ArticleID.aspx 对应的TrackBack URL：http://www.donews.net/$USERNAME/services/trackbacks/$ArticleID.aspx 题外话一下，donews的blog是基于开源的.Text系统，说真的，这套系统现在越看越差劲了，就拿这个trackback url接口来说，只要变换$ArticleID和$USERNAME就可以做到向不同的日志页面发送TB命令了。 对这个TB url进行技术处理实现隐藏就能达到最基本的anit-spam效果。TB URL不应该拿对应的文章ID号作接口，可以在文章生成时随机生成TrackBackID，而且不推荐用纯数字，纯数字容易循环，改成A-Za-z0-9 组合的字符串码，你用MD5加密ID后的字符串就完全可以实现这个功能。至于随机的tb url和日志页面的对应问题就更好解决了，在数据库中建立一张字典表，每个文章ID对应一条url就可以了。 利用强大的人为过滤方式。第二步，人肉过滤和人肉字典 每个用户在收到spam的trackback后可能会去删除，在删除操作时系统自动记录这条spam对应的ip地址，然后对spamIP进行数量上的分级，比如有10个用户(或者10次)提交了一个IP地址的spam，那么就认为这个ip是纯粹的危害性大的spam来源，直接整站屏蔽这条IP地址，不够10条的那就只在提交此IP的用户范围内进行过滤即可。这种方式估计是最有人情味和误判率最低的人肉过滤。想要更高级的，那就全世界范围内建立一个 spam字典库吧，通过信任登记的用户可以向该库提交spam数据，全球任何用户都可以从该库提出spam数据以供己用。 只让真正的用户才能得到url链接。第三步，日志页面内的TrackBack URL隐藏 看了第一条的你肯定会提出那spam系统难道不会从日志正文页面源码中提取url吗？的确是这样，高级的spam可以做到下载日志页面得到html 代码然后通过字符串查找轻松获取url链接，因为你的trackback肯定要提供给正常用户的。对于这种问题的解决其实很苛刻，实在想实现我想也是有办法的。利用验证码的方法在页面上以图片方式提供给读者url的地址，或者干脆不提供，放一个按钮，让用户点击该按钮，然后通过 xmlhttprequest不刷新当前页面从服务器上取到url链接返回给客户端，想做更好完全可以像我这样——。通过这种方式，只有真正的用户通过鼠标点击按钮后才能得到url地址。现在很多blog就采用这种机制，给你一个链接，提示你“单击查看引用地址”，单击后另开一个窗口显示trackback url，他们是通过页面来源地址的判断，来决定是否显示trackback url的。 至于韩磊所说的目前donews的spam烦恼我认为通过分隔服务器的方法最简单了，把接收trackback请求的操作从现有的服务器中分离出来，让tb指令全部在这台专有的服务器上操作，有效地请求排队加上重复命令过滤将很好的控制服务器的解析资源，同时向外公布的web服务器又不会因为过多的cgi请求而导致服务器资源严重占用。对于virushuo提出的对付trackback spam的方案我觉得更多的是防范恶意攻击，他把tb请求想象成类似于DDos的洪水攻击，说实话，我认为他的那套方案也不是和理想，众所周知，TCP/IP的通讯方式中有3次握手，DDos或者SYN攻击都是利用这3次握手的操作来达到攻击目的的，在目前基于TCP/IP的互联网上，想要真正解决这样的洪水攻击还没有一个好的解决方案。