记录一次自己使用的腾讯云服务器被挂马perfctl的排查及处理过程！同时吐槽一下腾讯云！
先吐个槽吧，腾讯云真的是不太行，无论是kubernetes集群在裸金属机器状态下部署的支持，还是简单的中小应用，感觉做的都不够理想，特别是客服系统，我昨天报这个问题的时候，客服首先做的不是排查问题，哪怕形式上极力帮我解决问题也可，而是发来两个文档，一个是购买他们的防护服务，另外一个是一篇官样文章，大概讲通常类似于矿机病毒很难被根除，可能我需要重新做系统，重新做系统要怎么做服务器加固，里面大概也就是建立ssh改端口记得重启，而且似乎还不是官方文档，是一篇类似于有通用性的社区文章，oh,my god!
昨天在搞论坛插件的时候，因为我有大量的运营帖子需要配图，我在专心的做这件事情，突然感觉服务器奇慢无比，这显然是非常不合理的，因为我自己的nginx服务器，是经过了层层优化的，整个Dockerfile是我自己编译安装了pagespeed这个gooogle提供的资源压缩的插件，并且相应的后端程序，无论是mariadb还是php程序或者是java程序，都经过了层层的优化，本地k8s集群上运行效果都极为迅速，我刚上线到腾讯云的时候，配有cloudflare加持，也是访问极其迅速的，这明显就不是它正常的运行状态，果不其然，我用top命令查看了一下，效果简直就匪夷所思了。
cpu占用超高，马上让我想起上次被挂马的经历，2022年的三月份的时候，当时也是被挂马，cpu占用超高，当时排查出来的原因就在于用的redis的镜像是老版本，导致virus通过漏洞就入侵到镜像里了，然后跑挖矿程序，简直一毛一样。我于是顺手搜了一上关于这个病毒的一些信息，发现遇到问题的看来不是我一个人。
freelancer上还有人发布悬赏任务，也是有点意思的。
国外老哥的解决方案也给出来了。
我当时立马就意识到，他的方式肯定不适合我，为什么呢？我的思路就是缘起于我上次的挂马经历，我只要把redis服务停掉，就没有cpu占用高的状况出现，一旦启动，立马飙高，所以肯定是它的原因。而这次，我观察运行进程的uid，你们看到了吧，是33，显而易见，没有以root权限运行，说明它肯定只是在镜像运行的时候，才会走它放毒的逻辑，所以肯定还是和镜像有关，我果断停掉了自己的一个php服务，果然perfctl的从占用排行榜中消失了。
那下面的任务就显而易见了，我必须先升级一下镜像，来观察一下是不是因为镜像所有语言版本不做维护了，所以就被开盒了，这种情况下只能升级了。一查果然如此php7.4的版本果然已经不维护了，好在我自己打版本的时候给php打了一个8.2版本一个7.4版本，只是7.4版本没有放xdebug扩展，而8.2版本不只把xdebug打进去了，swoole，opcache都打进去了，不过好在配置灵活，只要扩展加载路径文件夹里没有.so的文件及扩展配置不启用即可，于是把image声明成8.2，果断上传，心想应该像上次一样问题被瞬间拿捏了。
我还是低估了这个病毒的破坏力，我过了一段时间观察，发现perfctl又熟悉的出现在占用列表的榜首，显然升级官方维护的镜像并没有解决掉问题，我于是进一步查了一下有关这个病毒的信息，大家如果遇到也不妨一查，与其他病毒比较大的区别就在于隐蔽性好，当ssh登录态时可能会隐藏自己的运行状态，并且非常擅于伪装，非常擅于针对于系统配置文件层面的漏洞直接升级权限，把自己部署在系统启动文件里，而通常来说，操作系统的运行进程排查还是比较耗费时间的，你要看每个运行进行读取的配置文件，文件是否合法，文件是否符合常规文件的调用策略，我也试了网上一些国外大神的建议，但有些看看就知道不适用于我，因为我上面已经说了，他们好多都是root权限被劫持，而我的是在镜像里面，33通常就是www-data用户的组的标识，通常配合着nginx来做负载，很显然就是php-fpm的程序导致的这个问题，升级镜像又没解决这个问题，于是我能想到出现的原因，肯定就是php程序自身有漏洞，或者我开放了不该开放的访问权限，配置文件给了过高的权限，导致virus可以在部署目录里植入一些垃圾的矿机程序，所以我要做减法，我把php.ini中能堵上的漏洞全堵上，包括太不限于:
disabled_functions = exec, shell_exec, system, passthru, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source，把php层面上能进行脚本执行的相关函数全部禁用掉；- 指定程序执行目录
open_basedir =指定我php程序运行的几个目录，其他目录都不允许php程序执行 - 禁用所有的可视打印日志操作，改为logging记录
- 禁用
registry_globals - 禁用file_uploads
- 禁用allow_url_open,allow_url_include
- 给目录正确执行权限755，文件正确执行权限644
上传重启，到现在为止，没有发现perfctl重现。至于类似于file_uploads这种，肯定是不能禁用的，但是为了排查方便，如果确认问题解决，我再逐步放开即可。
希望这篇排查perfctl的文章对你有帮助，感谢阅读！
