转： http://blog.51cto.com/sery/1676611#

简单密码引起的血案

作者：田逸（sery@163.com）

正在努力搬砖，一阵急促的电话铃想起，同事紧急告知，论坛访问很慢，其它技术人员已经折腾了半天找不到原因，需要尽快处理。

首先简单了解了一些情况，运营的同事说前几天有管理员帐号被泄漏（咋泄漏的？设置简单密码，真像把后备箱那块砖拿过去拍他），被人用工具自动发帖，好家伙，一晚上发了上万个帖子。上午在qq群里看他们聊天，说费了很多时间才把这些垃圾帖子删掉。论坛的discuz程序没有做任何改动，怀疑是被恶意***。论坛不能访问已经大半天，来不及详细了解情况，挽起袖子，开干了。

再登录系统前，查阅资料确认整个论坛的逻辑拓扑，如下图所示：

注：此图省略了管理网络（通过***对服务器进行管理）

按这个拓扑结构，逐级进行检查和排错，具体步骤为：

（一）负载均衡器进行检查

1、检查系统负载、内存使用情况：输出表明是正常的；

2、检查磁盘空间使用情况，未发现有分区被塞满；

3、检查系统日志，为发现异常输出；

4、检查应用程序运行情况，执行命令 ipvsadmin ，有转发数而且数字不断变化，这可以确认应用程序keepalived 及lvs都是正常的。

由上面几点可确定负载均衡毫无问题，模拟故障切换，用户的请求也能自动切换到辅助负载均衡器。

（二）检查应用服务器

1、查看几个服务器的负载，load值好几十，严重超标；

2、查看磁盘空间使用情况，为发现使用率大于80%的分区；

3、查看系统日志，未发现文件系统损坏，内核异常之类的问题；

4、查看内存使用情况，未发现耗尽内存而占用交换分区swap的情况；

5、检查应用程序php及nginx，nginx无异常，而php偶尔有慢日志输出；

初步判断，是php引起的负载异常。关闭php片刻，系统负载很快降到正常水平。怀疑被人恶意***，通过查看tcp状态，也无有价值的线索。

如果被***，同一个ip的tcp连接数应该可能是很大的一个值。一般的经历，是上千上万的水平。尝试用iptables禁掉几个连接数多的源ip，效果不明显，负载还是很高。关掉php，负载降低，再启动，负载很快又爬升起来。看来，问题还不在这里。

（三）检查与应用服务器紧密关联的文件服务器

论坛程序是以nfs的方式共享给多个应用服务器使用的，这样的目的在于减少服务器之间的数据同步，假如不以共享的形式，则每个应用服务器都应保存一份完全相同的数据文件。因为一些数据文件随时间推移会不断发生变化，那么为了保证用户访问的一致性，就必须实时同步这些更新数据。

1、  检查系统负载、内存使用情况，发现一切正常；

2、  检查磁盘空间使用情况，未发现被塞满的分区；

3、  检查系统日志，未发现异常输出；

4、  检查nfs相关进程和配置，未发现异常；

以前发生过论坛访问异常的情况，引起的原因就是共享文件系统（nfs）分区文件系统损坏，导致nfs客户端（即php应用服务器）不能写入缓存。为了确认这个猜测，在文件服务器及客户端，都进行了创建和删除文件测试，一切正常。

（四）检查缓存服务器。

数据缓存使用的应用程序是memcached，这种服务器系统，仅仅运行这么一个应用，因为是内存存储数据，因此一般情况下，怀疑有故障，只需重启memcached，让它再重新缓存就好。

1、  检查系统负载、内存使用情况，一切正常；

2、  检查系统日志，无异常；

3、  检查网络状况，也很正常；

重启memcached，对应用服务器的负载毫无帮助，看来问题也不在这里。

（五）检查数据库服务器。

仅仅剩下它了，问题很显然，就与这个相关。吸一口带雾霾的空气，登录主数据库及从数据库服务器系统，进行如下常规排查。

1、  检查系统负载、内存使用情况，一切正常；

2、  检查磁盘空间使用情况，未发现被塞满的磁盘分区；

3、  检查系统日志，未发现异常输出；

4、  检查网络连接情况，主服务器连接数很少，而从服务器的连接数很多；这至少说明，在系统层面，主数据库服务器的正常的，从服务器系统，在系统层面看来，也基本认为是正常的。

本集群使用的论坛程序discuz本身支持数据库读写分离，因此主服务器的任务是承担数据更新的任务，而查询一类的工作，则由只读状态的从服务器（slave）承担。我们先层主服务器的应用层面进行排查，步骤如下：

（1）、检查mysql的错误日志及满查询日志，为发现异常输出；

（2）、检查mysql进程是否正常，执行mysql –p 登录一下，能进入mysql客户端命令行，守护进程正常；

（3）、mysql客户端执行命令 show full processlist;输出寥寥几行，一切在可以接受的范围；

由此判定，数据库主服务器无异常。

现在，山穷水尽，水落石出，问题多半就是这个从数据库服务器的问题了。系统层面的检查，为发现有用的线索。查mysql错误日志，未见异常；查mysql慢查询日志，果然有输出，而且还不断有新的输出。

一条sql语句好长啊，限于篇幅，不打算全副输出截图。登录mysql客户端，执行show full processlist; 天啦，好半天才输出完毕，线程数超过1000了（我设定的mysql最大连接数是1000），而输出的内容，大部分是慢查询里边的东东。用 mysql –p –e “show processlist;”>/root/sql_out 把这些sql形成一个文本文件，转发给程序员。他们看半天，也没有得出一个结论。有人建议杀掉看是异常的sql语句，但杀掉后，还是不行。大家还是怀疑被***，通过dns处理，把请求先定向到360，起到一定的***过滤作用。从监控见面看，确实有结果cc***被拦截。但对应用服务器的负载降低不起什么作用，并且论坛还是处于打不开的状态。

以超级系统管理员的帐号登录论坛后台，关闭论坛后，服务器负载立即恢复正常水平；再打开论坛，负载立马飙升。邪门了啊，居然在技术层面查不出问题所在。折腾了一天，头都大了。在qq群嚷了几句：“谁改了程序没有？谁在后台做什么设置没有啊？…..”,有人冒出来一句：“删垃圾贴的时候，为了快速删除，设置了页面显示帖子的数量值”。

我数学是政治老师教的，算不出多个板块多人访问的时候，具体要显示多少条记录，但大家都相信，这一定是很恐怖的一个数字。

发现问题，意识到问题的严重性。

论坛后台更改这个设置，几秒钟后，应用服务器的负载降下来了，从数据库的连接数也趋于正常，论坛也可以跟以前一样，可以浏览、发帖……

这一切，追溯起来，就是某些论坛管理员设置该死的简单密码。