Record a processing for diagnose a virus named perfctl to invasive my php-fpm image which deployed at tencent cloud,and how to solve the problem completely with harden techniques in php regions!

Yesterday in the forum plug-ins, because I have a large number of operational posts need to match the map, I was concentrating on this thing, suddenly feel the server is incredibly slow, which is obviously very unreasonable, because my own nginx server, is optimized through layers, the entire Dockerfile is my own compilation and installation of pagespeed this gooogle provides a resource compression plug-ins, and the corresponding back-end programs, whether mariadb or php programs or java programs are optimized through layers, the local k8s cluster run extremely fast. resource compression plug-in, and the corresponding back-end program, whether it is mariadb or php program or java program, have gone through layers of optimization, the local k8s cluster running effect is extremely fast, I just on-line to the tencent cloud, equipped with cloudflare support, is also accessed extremely quickly, this is obviously not the normal state of its operation, as a result, I used the top command to see the results. I used the top command to check it out, and the results were unbelievable.

! perfctl/image-1.png">alt text The cpu usage is super high, immediately reminds me of the last time I was mounted experience, in March 2022, at that time was also mounted, cpu usage is super high, at that time the reason is to use the redis image is an old version, resulting in virus through the loophole invaded to the image, and then run the mining program, it is exactly the same. I searched for some information about this virus and realized that I’m not the only one having problems.

! perfctl/image-2.png">alt text It’s also interesting to see that there is a bounty posted on freelancer.

! perfctl/image-3.png">alt text I’ve got a solution from a foreigner who’s also given it out.

I was immediately aware that his way was definitely not for me, why? My thinking was that it was because of my last experience with the horse, I just stopped the redis service, there was no high cpu usage, and once I started it, it immediately spiked, so it must be the cause. And this time, I observe the uid of the running process, you see it, is 33, obviously, not run with root privileges, that it must be only when the mirror is running, only to go it to put the logic of the poison, so it must still be related to the mirror, I decisively stopped one of their own php services, and sure enough, perfctl disappeared from the occupancy charts.

Then the following task is obvious, I must first upgrade the mirror, to observe whether it is because the mirror of all language versions do not do maintenance, so it is open box, this case can only be upgraded. A check is really so php7.4 version is really no longer maintained, good in my own version of the time to play a version of php 8.2 version of a 7.4 version, only the 7.4 version did not put the xdebug extension, while the 8.2 version is not only the xdebug into the swoole, opcache are played into the, but the good thing is that the configuration of the flexibility, as long as the extension load path folder does not have a .so file and extension configuration is not enabled can be, so the image declared as 8.2, decisively uploaded, thought it should be like the last time the problem was instantly pinpointed.

I still underestimated the destructive power of this virus, I observed after a period of time, found perfctl and familiar appeared at the top of the occupancy list, obviously upgrade the official maintenance of the mirror did not solve the problem, I then further check the information about this virus, you may also want to check if encountered, and other viruses is the big difference is that the concealment of the good, when the ssh login status may be will hide their own running state, and very good at camouflage, very good at the system configuration file level of the vulnerability of the direct escalation of privileges, deployed in the system startup file, and in general, the operating system is still more time-consuming to run the process of scheduling, you have to look at the configuration file of each run to read the file, the file is legitimate, the file whether the file is in line with the conventional file call strategy, I also tried I also tried some foreign god’s advice on the Internet, but some of the look at know does not apply to me, because I have said above, many of them are root privilege hijacking, and mine is in the mirror, 33 is usually the www-data user’s group identification, usually with the nginx to do the load, it is clear that the program is the php-fpm cause this problem, upgrade the mirror and did not solve the problem, so I can think of the emergence of this problem, so I can think of a good way to solve this problem. This problem, so I can think of the reason, must be the php program itself has a loophole, or I open the access rights should not be open, the configuration file to give too high permissions, resulting in virus can be in the deployment directory implanted in some of the garbage mining program, so I have to subtract, I will be in the php.ini can plug all the holes blocked, including too not limited to.

1. disabled_functions = exec, shell_exec, system, passthru, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source to disable all functions that can execute scripts on the php level. to disable all functions that can execute scripts at the php level;
2. specify the directory where the program is to be executed open_basedir = specify the directories where my php program is to be run, all other directories are not allowed for the execution of the php program.
3. disable all visual logging operations and replace them with logging.
4. disable the registry_globals.
5. disable file_uploads
6. disable allow_url_open,allow_url_include
7. give directory proper execution permissions 755 and file proper execution permissions 644

Uploaded and restarted, no perfctl reappearance so far. As for something like file_uploads, you definitely can’t disable it, but for the sake of troubleshooting, if I confirm the problem is solved, I’ll just gradually release it.

I hope this troubleshooting perfctl article is helpful to you, thanks for reading!