起因：

阿里云服务器再次警告出现挖矿程序。上一次服务器被攻击后，怕有恶意程序残留，第一时间重装了系统，也没有详查攻击入口。不过事后还是做了一些防范，这台留作公网访问的服务器上并未保留业务数据，只作为中转使用。因而这次也就没什么担心的，准备详细研究一下攻击入口在哪里。

过程：

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的访问进行了限制，既能防范攻击也不影响正常业务请求：

结论：

我们往往只关注自己了解的领域或者知识，将工作重心放在业务层面。然而，“后勤保障团队”虽不光鲜亮丽，仍然不可忽略，就像有些程序员不屑于写注释和文档，迟早有一天会为自己的高傲买单，这时的花费可能远超组建“后勤保障团队”。