09年,有一款脚本相当流行,通过创建随机的tag以及分类,或者给搜索参数添加随机数字/字符串来达到拖挂MySQL的目的。

其实不单单对于对搜索没有防备的WordPress有效,对于任何资源有限,而执行时间比较长,没有缓存的操作,都有一定的杀伤力,如果IP数量比较多,且持久的进行测试/攻击,那么便可以造成拒绝服务的效果。

昨天发帖之后,有个童鞋倒是提醒了我,于是更新了一下内存缓存的策略。

  • 首先最重要的一点是限制请求的频率,iptables和fail2ban是对好基友,交给他们妥妥的。
  • 附带着用nginx把连接数也限制掉,最后降低redis中对于搜索结果页面的缓存时间。
  • 其实使用了object-cache后,击穿redis中的mysql快照的可能性本身就小了很多
  • 顺带还做了一些其他的事情,不过不重要了,来聊聊站内搜索好了。

搜索无意是计算机乃至互联网中的一项重要功能,有个段子,linux中重要的工具都变成了网络服务,其中grep变成了Google。

但是对于个人博客来说,就不尽然了。

首先个人站点内内容数量少,不算BSP上写过的内容,光是这个WP站,也有7~8年的历史了,但是文章不过千余,而根据最近30天的统计数据来看,只有32%的人会是直接访问网站,而多数人都是因为特定的文章或者推荐,直接到达想要获取的内容的页面,一般来说,访客在看到内容,或者下载完毕附件之后就会离开,除非你的内容激起了共鸣或者聚合了一堆他感兴趣的事情,观察数据,后者只有24.99%,并且后者多数是通过翻看类目下的文章来进行内容的获取。

继续观察数据,某些页面成为入口页面的比重就大于首页10%以上是常见状态,而平均停留时长为4~5分钟,恰好足够阅读一篇热点文章,而没有给额外的交互操作留下时间,加之直接来访的跳出率有64%,所以,搜索功能弱化掉,只放在首页,个人觉得比较合适。

并且,对于搜索内容,因为在页面元标签内限定了机器人none,所以,会重复进行接口访问的,一般来说只有正常人和来捣乱但是我不会给糖的孩子了,而正常人不会有太多的搜索交互,除非他输入法过愚人节嗨的停不下来,或者文章内有太多的暗示去搜索,以及给出了搜索链接,而这些我都不会去做(忘记了,还有我自己,或许我是使用搜索功能的最大用户了吧,下次做个统计)。

最后补一下开头说的Search flood exploit问题,在wordpress trac中ticket的地址: