起因：

阿里云服務器再次警告出現挖礦程序。上一次服務器被攻擊后，怕有惡意程序殘留，第一時間重裝了系統，也沒有詳查攻擊入口。不過事后還是做了一些防范，這臺留作公網訪問的服務器上并未保留業務數據，只作為中轉使用。因而這次也就沒什么擔心的，準備詳細研究一下攻擊入口在哪里。

過程：

1. 查看檢測出的挖礦程序php_cci.exe。幾乎是第一眼就看到下邊這個cn.php文件。exe文件干了啥我不清楚，但是php是腳本文件，可以放心大膽地打開看看。

????

腳本內容就不貼出來了，以下是deepseek對腳本的部分分析：

????

2. 推測攻擊方式。根據兩個文件的修改時間，我大概判斷php_cci.exe是通過cn.php下載至本地的。那么cn.php是如何來的呢？這臺服務器只對公網開放了遠程連接及web端口，上次被攻擊時阿里云有短信提示遠程連接在異地登錄，這次沒有，而且可疑文件是php腳本，所以幾乎可以斷定就是web漏洞了。

3. 鎖定攻擊入口。確定是web漏洞后，便直接查看apache目錄下的access.log，檢查可疑請求，重點是cn.php文件創建時間左右的POST請求。果不其然，有一條對php-cgi.exe的訪問請求，一看就不是什么正經請求。

完整請求如下：

POST /php-cgi/php-cgi.exe?%ADd+cgi.force_redirect%3D0+%ADd+disable_functions%3D%22%22+%ADd+allow_url_include%3D1+%ADd+auto_prepend_file%3Dphp://input HTTP/1.1" 500 638 "-" "python-requests/2.27.1

這是一條典型的php-cgi參數注入攻擊。雖然服務器返回了500，但仍然可能被感染了。

4. 本地構造請求復現攻擊。我用python構造請求，POST內容為將當前時間寫入桌面上一個文件中：

<?phpfile_put_contents("C:/Users/Administrator/Desktop/error.txt", date('Y-m-d H:i:s'));?>

當然，中間是經歷了一些挫折的，但最終確實攻擊成功了。

5. 修改配置防范此類攻擊。查詢了資料也問了AI，嘗試了幾種方案效果不是很好。最終還是簡單粗暴地對php-cgi.exe的訪問進行了限制，既能防范攻擊也不影響正常業務請求：

結論：

我們往往只關注自己了解的領域或者知識，將工作重心放在業務層面。然而，“后勤保障團隊”雖不光鮮亮麗，仍然不可忽略，就像有些程序員不屑于寫注釋和文檔，遲早有一天會為自己的高傲買單，這時的花費可能遠超組建“后勤保障團隊”。