Wordfence的log导致WordPress数据库增大

Wordfence是一款由Feedjit开发并运营的WordPress应用防火墙,主要用于监控入站流量、检测并防御针对WordPress的网络攻击。功能涵盖从扫描WordPress主要文件是否遭到更改、是否存在恶意插件(后门)、暴力登录、弱密码攻击,到过滤垃圾留言、分析Google爬虫行为等等非常广泛。

我的Blog安装这个插件已经一年多了,总体状况还算满意。对性能几乎没有(可以主观感受到的)影响,而且通过后台观察统计数据也的确防范了一些攻击(然而没有防御先前的API提权漏洞攻击)。

前些天在整理数据库备份的时候偶然发现,WordPress的数据库这一年以来增大了几乎一倍,而目前托管在我这的几个网站几乎都处于停滞状态,文章和留言几乎都没有增加。

继续阅读Wordfence的log导致WordPress数据库增大

WordPress 4.7和4.7.1的提权漏洞

今天VempX联络我说Blog被黑了。结果我一看我俩的Blog、爱乳发布页都被黑了。症状是最新一条Blog文章遭到修改,标题和内容变成了“Hacked By BALA SNIPER”。

我的WordPress用的是强密码且不存在密码重复使用的问题,平日里后台也做了不少加强安全性的工作。因此可以初步排除爆破、撞库、社工渗透的可能性。

继续阅读WordPress 4.7和4.7.1的提权漏洞

利用dnsmasq和nginx阻断HTTP流量劫持(解决篇)

上篇文章中已经说过,一些“不可抗力”会利用对关键网络设备的控制权,在用户不知情的情况下,将用户网购的HTTP流量劫持到己方控制的服务器,加入推广链接达到获得私利的目的。“不可抗力”们并没有在电商的推广过程中加入任何附加价值,滥用推广返利,违背了用户和电商双方的初衷。

由于HTTP流量劫持发生在运营商机房里,脱离了用户可以控制和防范的范围,除了收集100%强力的证据,威胁客服或者投诉工信部以外,防范和解决起来相对比较困难。本文用比较EP的技术手段,在家庭局域网内阻断流量劫持,拒绝“尾巴”,纯净访问电商。 继续阅读利用dnsmasq和nginx阻断HTTP流量劫持(解决篇)

网络运营商耍流氓的新手段——HTTP劫持电商流量套取返利(分析篇)

随着DNS劫持手段越来越容易被识破和防范,TCP流量劫持这一新的手段出现了 。这种攻击手段通过运营商路由设备将发往特定域名(或IP)的流量阻断,并返回预设的内容(通常是广告或重定向请求)。TCP流量劫持手段不光隐蔽,无法通过更换DNS服务器防范(用户更换其他DNS后仍会被劫持),容易推卸责任(就算用户投诉,往往也可以通过“用户中毒”或“网站被挂马”等说辞混淆视听),还容易根据用户个人信息(事先收集到的年龄、收入水平、所选套餐等)、时间段、用户平时浏览与购物习惯等精确推送广告,近来越发受到运营商青睐。

继续阅读网络运营商耍流氓的新手段——HTTP劫持电商流量套取返利(分析篇)

eAccelerator与php 5.4的兼容问题

NMM的文档库采用了MediaWiki,运行在nginx + php5 + mysql环境里,并由eAccelerator优化,由memcached进行缓存。

前天将服务器的php从5.3.12升级到了5.4.19,然后MediaWiki就白屏了。查了error log之后发现php产生了下面这条错误:

继续阅读eAccelerator与php 5.4的兼容问题

h5ai界面设计变得扁平

前天把NMM从BurstNET的vps迁移到了新租用的Linode的VPS,顺便把服务器的一系列应用都升级了一圈。

比如,PHP从5.3.12升级到了最新的5.4.19,mediawiki也升级到了最新的1.21.2。然后偶然发现一直用于tmod目录列表的h5ai也有新版了,于是从0.21.1升级到了0.24。h5ai最早是一套用于美化apache目录列表的套件,可以让生硬难看的apache默认目录列表变得优雅而又充满便利的功能。后来h5ai推出了php组件,凡是支持php环境的web server均可使用。这样以来不光是apache,nginx、切诺基、lighttpd也可以沾光了。我(为了省事_,)在为taro提供的空间里也用了这个套件。

回到正题,升级好之后忽然发现界面设计变了,原先包含渐变、圆角和「拟物质感」的设计变为单色、扁平、直角风格。

0.21 => 0.21
(0.21.1)    (0.24)

看了一下changelog,发现这个变成发生在今年7月发布的0.23版中。好吧……又一个摩登设计诞生了。

距Google Reader下线还有10天 新版Feedly Cloud上线

今天访问 Google Reader 的时候又被提示说 Google Reader 7月1日即将下线,于是只好开始试图认真地寻找替代服务。之前写过一篇文章说 Feedly 不错,试用了一段时间,感觉有两点不是很愉快:

  • 没有 web 模式:浏览器必须安装其 add-on 才可以使用。
  • 擅自更改链接:Feedly 会在链接后面加上“?utm_source=feedly”这一 query string ,导致很多使用 url rewrite 的网站无法正确处理篡改过的 url 。

“必须安装些什么才能用”,或者“擅自改变原本的东西”这两点让人觉得不安、不适,让我难以信任这款产品。 继续阅读距Google Reader下线还有10天 新版Feedly Cloud上线

Reader已死 有事烧纸

(正确的说是Google Reader。)

去年的今天我很兴奋。因为明天传说中的the New iPad就能送到我的手上了。从那以后iPad几乎成了我的床机,睡觉前、起床后刷刷推,看看新闻,甚至还买过几件衣服。

今天早晨10:00(东京时间)起床后我照常刷了刷推,除了昨晚的紧急地震速报以外(<-睡如死猪没知觉),几乎所有(中文)用户都在奔走相告Google Reader即将关闭的消息。我打开Reeder,通过Google Reader API同步过来的Feed看到西贝上也充满了GR相关的新闻,然后转向了Feedly。

阅读器的本职工作是将分散在四处的信息汇聚起来,并以容易阅读的方式呈现给读者。但Google Reader所做的远远不止这点。Google Reader具有:

  1. 极其稳定的工作状态和及时的内容抓取。
  2. 不仅仅提供收藏、评价等提供个人使用的功能,还允许用户通过分享、评论等操作互相交流(尽管此功能后来被Google阉割)。
  3. 开放API允许第三方应用获取用户订阅的内容,并同步阅读状态。
  4. 提供Feed正文(尽管可能不一定是全文)的存储,就算网站关闭也能阅览以前的内容。以及——
  5. 跨语言的高效的搜索。

“汇聚”和“易读”不难做到,甚至有很多阅读器(包括基于Google Reader API的)做得比Google Reader好很多。但是以上几点,特别是第4、5两点需要经验、技术和长期运营中不断的积累。用户们需要得不光光是一个能看新闻的阅读器,他们还需要一个属于自己的Web/RSS Archive和搜索引擎。我不觉的目前哪个阅读器能够完全替代Google Reader,就是这两样不是7月1日以前就能积累完成的。

失去了Google Reader的RSS会走么?跟着他的作者一起。