CWP7 Security Audit warnings

CWP7 Security Audit: Ghost Files and False “Unauthorized port: php-fpm” Alert After Updates
Topic


Server: Rocky Linux release 9.7 (Blue Onyx)
Apache version: Apache/2.4.65
PHP version: 7.3.0
MySQL version: 10.11.15-MariaDB
FTP version: 1.0.52

CWPpro version: 0.9.8.1224



This article explains a CWP7 security audit issue where the audit script reported:

[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found
[SECURITY ALERT] Unauthorized port: php-fpm

In this case, the server was clean, but two different issues appeared together:

Old deleted system libraries were still held in memory by the CWP PHP-FPM process.
The audit script incorrectly interpreted a Unix socket as a TCP port.

The server environment was CWP7 with cwpsrv and cwpsrv-phpfpm.

Problem

The audit command showed this warning:

sh /scripts/cwp_security_audit

Example output:

[INFO] Auditing php-fpm-cwp (PID: 3884380)
[!!! CRITICAL ALERT !!!] Ghost files (deleted but running) found:
php-fpm 3884380 root DEL REG /usr/lib64/libkrb5support.so.0.1
php-fpm 3884380 root DEL REG /usr/lib64/libkrb5.so.3.3
php-fpm 3884380 root DEL REG /usr/lib64/libk5crypto.so.3.1
php-fpm 3884380 root DEL REG /usr/lib64/libgssapi_krb5.so.2.2

[SECURITY ALERT] Unauthorized port: php-fpm

At first sight this looks critical. However, these files were normal system Kerberos/GSSAPI libraries. After a system update, the files on disk had been replaced, but the already-running php-fpm process was still holding the old deleted versions in memory.

Also, the second warning was misleading:

[SECURITY ALERT] Unauthorized port: php-fpm

php-fpm was not listening on a TCP port. It was listening on a Unix socket:

/usr/local/cwp/php71/var/sockets/cwpsrv.sock

The audit script parsed this Unix socket line incorrectly and treated the word php-fpm as if it were a port number.

Solution
1. Check the running PHP-FPM process

First, identify the process shown in the audit output.

Replace the PID with your own PID:

ps -fp 3884380

Example output:

UID        PID       PPID  CMD
root       3884380   1     php-fpm: master process (/usr/local/cwp/php71/etc/cwpsrv.conf)

Then check the real executable:

tr '\0' ' ' < /proc/3884380/cmdline; echo
readlink -f /proc/3884380/exe
ls -l /proc/3884380/exe

Expected output should be similar to:

php-fpm: master process (/usr/local/cwp/php71/etc/cwpsrv.conf)
/usr/local/cwp/php71/sbin/php-fpm
/proc/3884380/exe -> /usr/local/cwp/php71/sbin/php-fpm

This confirms that the process belongs to CWP and is not running from /tmp, /dev/shm, or another suspicious location.

2. Check the ghost files

Run:

lsof -p 3884380 | grep -E 'DEL|deleted|krb5|gssapi|k5crypto'

If the result only shows normal system libraries like these:

/usr/lib64/libkrb5support.so.0.1
/usr/lib64/libkrb5.so.3.3
/usr/lib64/libk5crypto.so.3.1
/usr/lib64/libgssapi_krb5.so.2.2

then it is most likely caused by a system update. The running process still has old libraries open in memory.

3. Find the correct systemd service

Do not restart random services. First check which service owns the process:

cat /proc/3884380/cgroup

Example output:

0::/system.slice/cwpsrv-phpfpm.service

This shows that the correct service is:

cwpsrv-phpfpm

Check its status:

systemctl status cwpsrv-phpfpm --no-pager -l
4. Test the PHP-FPM configuration

Before restarting, test the configuration:

/usr/local/cwp/php71/sbin/php-fpm -t -y /usr/local/cwp/php71/etc/cwpsrv.conf

Expected result:

NOTICE: configuration file /usr/local/cwp/php71/etc/cwpsrv.conf test is successful

If the configuration test is successful, restart the service:

systemctl restart cwpsrv-phpfpm

Then check the service again:

systemctl status cwpsrv-phpfpm --no-pager -l

After restart, the main PID should change and the service should be active.

Tests
1. Check deleted libraries again

Use the new PID from systemctl status.

Example:

lsof -p NEW_PID | grep -E 'DEL|deleted|krb5|gssapi|k5crypto'

After restart, the Kerberos/GSSAPI libraries should no longer appear as DEL.

They should appear as normal memory-mapped files, for example:

php-fpm NEW_PID root mem REG /usr/lib64/libkrb5support.so.0.1
php-fpm NEW_PID root mem REG /usr/lib64/libkrb5.so.3.3
php-fpm NEW_PID root mem REG /usr/lib64/libk5crypto.so.3.1
php-fpm NEW_PID root mem REG /usr/lib64/libgssapi_krb5.so.2.2

This means the ghost library issue is solved.

2. Check whether php-fpm listens on a TCP port

Run:

ss -lntp | grep -E 'php-fpm|cwpsrv'

In this case, only cwpsrv was listening on normal CWP ports:

2030
2031
2082
2083
2086
2087
2095
2096
2302
2304

php-fpm was not listening on a TCP port.

Then check the raw lsof output:

lsof -p NEW_PID -nP | grep LISTEN

Example result:

php-fpm NEW_PID root 6u unix /usr/local/cwp/php71/var/sockets/cwpsrv.sock type=STREAM (LISTEN)

This confirms that php-fpm is using a Unix socket, not a TCP port.

3. Fix the audit script port parsing issue

First, make a backup:

cp -a /scripts/cwp_security_audit /scripts/cwp_security_audit.bak_$(date +%F_%H%M%S)

Then edit the port audit logic.

Original problematic line:

local CURRENT_PORTS=$(lsof -p $PID -nP | grep "LISTEN" | awk -F':' '{print $NF}' | awk '{print $1}')

Replace it with:

local CURRENT_PORTS=$(lsof -a -p $PID -nP -iTCP -sTCP:LISTEN 2>/dev/null | awk 'NR>1 {print $9}' | awk -F':' '{print $NF}' | sed 's/[^0-9].*$//' | grep -E '^[0-9]+$')

This new command only checks real TCP listening ports. It ignores Unix socket listeners such as:

/usr/local/cwp/php71/var/sockets/cwpsrv.sock

So the script no longer mistakes php-fpm for a port number.

4. Run the audit again

Finally, run:

sh /scripts/cwp_security_audit

Expected clean result:

------------------------------------------------------
[INFO] Auditing cwpsrv
[OK] cwpsrv looks clean.
------------------------------------------------------
[INFO] Auditing php-fpm-cwp
[OK] php-fpm-cwp looks clean.
------------------------------------------------------
[INFO] Auditing apache
[OK] apache looks clean.
------------------------------------------------------
[DONE] Security audit finished.
Result

The issue was solved in two parts:

The “ghost files / deleted but running” warning was caused by old system libraries still held in memory after updates. Restarting cwpsrv-phpfpm solved it.
The “Unauthorized port: php-fpm” warning was a false positive. The audit script was parsing Unix socket LISTEN lines as if they were TCP ports. Updating the port audit line fixed the problem.

Final audit result:

[OK] cwpsrv looks clean.
[OK] php-fpm-cwp looks clean.
[OK] apache looks clean.
[DONE] Security audit finished.

In this case, there was no evidence of compromise. The issue was caused by normal post-update behavior plus a small parsing bug in the audit script.