This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1
Other / Re: root ssh authorized_keys file has been deleted and password login allowed
« on: July 23, 2026, 09:41:40 PM »
The issue arises from how the CWP `temp_hacker_check` script handles SSH keys during its daily cleanup process: the script is poorly coded and removes SSH keys for a specific list of users—including the `operator` user, which shares the same home directory as the `root` user (`/root`).
When it deletes the contents of the `operator` user's `.ssh` directory, it inadvertently deletes the contents of `/root/.ssh` as well.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the `operator` user's home directory:
The `operator` user is a standard user created by Linux long ago, specifically for backups. It is created with the same user ID as *root* (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers several days ago; it is working well, and the `root` user's SSH keys are no longer being deleted.
Avoid altering the script itself, as your changes could be overwritten in the future by new updates to the `temp_hacker_check` script.
There is no need to disable SSH; simply run the command above.
SSH is your best ally for server administration and is very secure, provided you properly protect your keys.
Best regards,
Netino
When it deletes the contents of the `operator` user's `.ssh` directory, it inadvertently deletes the contents of `/root/.ssh` as well.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the `operator` user's home directory:
Code: [Select]
# usermod -d /root/operator operator
The `operator` user is a standard user created by Linux long ago, specifically for backups. It is created with the same user ID as *root* (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers several days ago; it is working well, and the `root` user's SSH keys are no longer being deleted.
Avoid altering the script itself, as your changes could be overwritten in the future by new updates to the `temp_hacker_check` script.
There is no need to disable SSH; simply run the command above.
SSH is your best ally for server administration and is very secure, provided you properly protect your keys.
Best regards,
Netino
2
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« on: July 09, 2026, 11:41:57 PM »
The issue with the 'temp_hacker_check' script's SSH key removal process is that the script is poorly coded; it removes SSH keys for a specific list of users, including the 'operator' user, which shares the same home directory as the 'root' user (/root).
By deleting the contents of the .ssh directory from 'operator' user, it inadvertently deletes the contents of /root/.ssh.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the 'operator' user's home directory:
The 'operator' user is a standard user created by Linux long ago specifically for backups. It is created with the same user ID as root (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers six days ago; it is working well, and the 'root' user's SSH keys are no longer being deleted.
Regards,
Netino
By deleting the contents of the .ssh directory from 'operator' user, it inadvertently deletes the contents of /root/.ssh.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the 'operator' user's home directory:
Code: [Select]
# usermod -d /root/operator operatorThe 'operator' user is a standard user created by Linux long ago specifically for backups. It is created with the same user ID as root (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers six days ago; it is working well, and the 'root' user's SSH keys are no longer being deleted.
Regards,
Netino
3
Other / Re: The CWPpro version 0.9.8.1239 update destroyed sshd and .ssh.
« on: July 02, 2026, 07:20:03 AM »
Same here.
Deleted ~/.ssh/ from all of my servers.
I'm using Alma8.
Shocked, because I'm was thinking I was hacked all my servers.
Regards,
Netino
Deleted ~/.ssh/ from all of my servers.
I'm using Alma8.
Shocked, because I'm was thinking I was hacked all my servers.
Regards,
Netino
4
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« on: June 18, 2026, 02:11:21 AM »
Guys,
I had these problems with an eval($_POST['shell']) type attack in the logs, in the admin area, two years ago (Jun/07/2024).
It was saving an error.php file in an area restricted to the admin, and running it.
In other words, somehow CWP was allowing files to be saved in the admin's restricted area.
I informed the CWP team, but I haven't received any feedback, and I don't know if it was resolved or not.
So, I proposed a temporary solution of restricting access to the admin area with the nginx server password, because the 'cwpsrv' process is actually 'nginx'.
This attack is very similar to the one that happened two years ago, so I have reason to believe that this attack is related to the attack from that time.
But since then, after restricting the admin area, I haven't had any more problems of this type.
So, if you are having problems even after updating to the new version of CWP, and have still suffered attacks, I recommend that you restrict the admin area with the nginx password.
You and your users will still be able to use CWP, as long as you have the specified password.
This doesn't solve the problem, but it brings much more peace of mind to day-to-day use until there is time to discover and fix the real problem.
To restrict the admin area, run this script:
You can choose any password you want, but choose wisely.
Regards,
Netino
I had these problems with an eval($_POST['shell']) type attack in the logs, in the admin area, two years ago (Jun/07/2024).
It was saving an error.php file in an area restricted to the admin, and running it.
In other words, somehow CWP was allowing files to be saved in the admin's restricted area.
I informed the CWP team, but I haven't received any feedback, and I don't know if it was resolved or not.
So, I proposed a temporary solution of restricting access to the admin area with the nginx server password, because the 'cwpsrv' process is actually 'nginx'.
This attack is very similar to the one that happened two years ago, so I have reason to believe that this attack is related to the attack from that time.
But since then, after restricting the admin area, I haven't had any more problems of this type.
So, if you are having problems even after updating to the new version of CWP, and have still suffered attacks, I recommend that you restrict the admin area with the nginx password.
You and your users will still be able to use CWP, as long as you have the specified password.
This doesn't solve the problem, but it brings much more peace of mind to day-to-day use until there is time to discover and fix the real problem.
To restrict the admin area, run this script:
Code: [Select]
if [[ ! -e /usr/local/cwpsrv/conf/include/security.conf ]]; then
read -p "Install additional authentication layer to CWP? (Y/n): " -r
echo # (optional) move to a new line
if [[ $REPLY =~ ^[Ss]$ ]]; then
# To create additional password to use cwpsrv
# It will work on the block ports 2031 e 2087:
# Replace XY.XW.XZ.XX with any IP address if you want restrict a IP adresses, or delete 'allow' lines
# Creating the file /usr/local/cwpsrv/conf/include/security.conf with the following content:
echo "Creating additional authentication layer to cwpsrv..."
IP_REMOTO_ATUAL=$(w -i| grep root | cut -d' ' -f10| head -1)
cat << EOT > /usr/local/cwpsrv/conf/include/security.conf
satisfy any;
allow XY.XW.XZ.XX;
allow 127.0.0.1;
deny all;
auth_basic "Protected site";
auth_basic_user_file /usr/local/cwpsrv/conf/htpasswd;
EOT
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!! Now creating the password to additional authentication layer to CWP server !!!!"
echo " ( You can choose any password you want )"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "root:"$(openssl passwd -apr1) > /usr/local/cwpsrv/conf/htpasswd
if [[ $? -eq 0 ]]; then
echo "Password sucessfully configured!"
else
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!.....ALERT.......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "There was some problem, and was not possible to configure the password, you must verify the problem!"
fi
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
fi
fi
read -p "Press [enter] to restart cwpsrv"
/scripts/restart_cwpsrv
You can choose any password you want, but choose wisely.
Regards,
Netino
5
SSL / Re: Recommended acme.sh cron for CWP AutoSSL renewals?
« on: May 26, 2026, 11:48:42 PM »
I'm using the following syntax in my scripts, and they're working::
The "bash" part is not necessary because the script "/root/.acme.sh/acme.sh" already has execute permission.
Regards,
Netino
Code: [Select]
# /root/.acme.sh/acme.sh --home /root/.acme.sh/cwp_certs
\___________________/ \_____________________/
^ ^
This is the program part This is home directory part
The "bash" part is not necessary because the script "/root/.acme.sh/acme.sh" already has execute permission.
Regards,
Netino
6
Nginx / Re: Nginx uploads fail after every package update on CWP / AlmaLinux 8
« on: May 25, 2026, 11:45:32 PM »try to add the custom "chown", "chmod" commands to:
/etc/cron.daily/cwp
right after:Code: [Select]/usr/local/cwp/php71/bin/php -d max_execution_time=1000000 -q /usr/local/cwpsrv/htdocs/resources/admin/include/cron.phpto fix the permissions after the daily cwp update.
I prefer my approach but yours also works.
But this issue happens to someone else? I have it on all my servers.
Yes, I'm having the same problem, and I'm resolving it with `chown` when it occurs. I even removed `/var/lib/nginx` from the installation, but then I needed to do some CWP migrations, and everything went back to square one. So, I'll make time to study and use your approach.
7
Installation / Re: Best solution for migrate active server from Centos 7 to another distro
« on: November 05, 2025, 12:13:23 AM »You could try to ELevate the system, but Sandeep (a CWP dev) recommends against it (it can introduce inexplicable oddities). The best course is to install a fresh AlmaLinux 8 system and use CWP Migration to move all accounts, sites, and e-mails over to the new server. If you are very knowledgeable, you could try to manually migrate to AlmaLinux 8 or 9:
I would agree with this solution, but this simply would not work in OpenVZ, OpenVirtuozzo, or alike systems.
He needs to know their system.
Or put the details here.
Regards,
Netino
8
PHP / Re: PHP Warning: PHP Startup: Unable to load dynamic library 'intl'
« on: July 03, 2025, 12:43:04 AM »
It is claiming about 'libicui18n.so.60' shared object file.
This is a too old library, and seems not available in any package to AL9, that uses GLIBC_2.34.
I think you will need to compile and install libicu 60.3 manually.
This is a too old library, and seems not available in any package to AL9, that uses GLIBC_2.34.
I think you will need to compile and install libicu 60.3 manually.
9
PHP / Re: PHP Warning: PHP Startup: Unable to load dynamic library 'intl'
« on: July 01, 2025, 01:50:29 AM »
Try to search here:
https://rpmfind.net/linux/rpm2html/search.php?query=php74-php-intl
The last version today is:
https://rpmfind.net/linux/remi/enterprise/9/remi/x86_64/php74-php-intl-7.4.33-23.el9.remi.x86_64.rpm
Regards,
Netino
https://rpmfind.net/linux/rpm2html/search.php?query=php74-php-intl
The last version today is:
https://rpmfind.net/linux/remi/enterprise/9/remi/x86_64/php74-php-intl-7.4.33-23.el9.remi.x86_64.rpm
Regards,
Netino
10
How to / Re: [Howto] Install Rspamd
« on: July 01, 2025, 01:28:46 AM »
@overseer,
You are right, sorry for the typo.
Unfortunately, this forum doesn't let to edit that post anymore.
Thanks anyway for the correction.
You are right, sorry for the typo.
Unfortunately, this forum doesn't let to edit that post anymore.
Thanks anyway for the correction.
11
CentOS 9 Problems / Re: Disk full
« on: June 24, 2025, 01:44:38 AM »
Install ncdu:
Navigate to the directory you want to search and simply run 'ncdu'.
This will show you how much disk space is consumed by each subdirectory.
Regards,
Netino
Code: [Select]
# dnf install ncduNavigate to the directory you want to search and simply run 'ncdu'.
This will show you how much disk space is consumed by each subdirectory.
Regards,
Netino
12
Installation / Re: Broken uninstallable packages
« on: June 18, 2025, 01:54:27 AM »
I agree, mariadb is a strong candidate to this problem, if the user did not updated as indicated.
Unfortunately, the graphical update of the CWP does not show which package(s) contain the error(s).
Try establishing an SSH connection and performing the manual update with the following command:
...and follow the possible program interactions.
Regards,
Netino
Unfortunately, the graphical update of the CWP does not show which package(s) contain the error(s).
Try establishing an SSH connection and performing the manual update with the following command:
Code: [Select]
# dnf update
...and follow the possible program interactions.
Regards,
Netino
13
How to / Re: [Howto] Install Rspamd
« on: June 18, 2025, 01:40:38 AM »Netino, what's your average daily mail message volume?
I have a low volume of emails, on three servers, about 4 thousand messages per day. But even with this volume, it was enough to consume about 70% of the resources of this server with Spamassassin.
Today, I am using the same rules of Spamassassin, but with only about 2% of the resources of the servers, the difference in resource savings is brutal.
For a small server, this makes a lot of difference.
14
How to / Re: [Howto] Install Rspamd
« on: June 18, 2025, 01:34:24 AM »Has anyone tested this tutorial on CWP with AlmaLinux 8? Did it work?
Yes, I am running this setup on an AL8.
I have certainly added a few more modules, but this is up to your taste or needs, this is a basic setup, adapted to CWP.
If you wish, you can add any modules you want.
15
PHP / Re: AH01075: Error dispatching request to : (polling)
« on: May 24, 2025, 12:22:59 AM »The problem isnt with phpfpm restarting @netino. It is something else.
cron logs:
(...)
Uptimerobot says site was down at 01:12:34 but it has a 5 minute interval.
So it can be down from 01:07.
Yeah, it doesn't seem to be something triggered by cron. I see you have CXS, but I don't know what the /etc/cxs/cxsdbupdate.pl script does, it would be good to check.
Quote
In accesslog the last line with http 200 code is this:
[23/May/2025:01:08:23 +0200] "POST /wp-admin/admin-ajax.php HTTP/2.0" 200
The first with a 504 error is this
Could it be a crawler taking down the site?
Is it your web server that goes down? If that's the case, you need to check the log in the file '/usr/local/apache/logs/error_log' around that time.
The AH01075 error doesn't seem to be related to this web server crash, because it's a very common error, and I have dozens of them on my server, and it has never crashed because of this error in 8 years.
Quote
[23/May/2025:01:07:58 +0200] "GET /robots.txt HTTP/1.1" 504 247 "-" "Mozilla/5.0 (compatible; SemrushBot-BA; +http://www.semrush.com/bot.html)"
Yes, this is a bot, but I don't think it can take down a server unless your server is already overloaded. It will make a lot of connections, and if the server is already overloaded, it could crash.
Most likely, your web server has already experienced problems, and simply can't serve the page.
According to the website <https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/504>:
"The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not receive a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.
There are many causes of 504 errors, and fixing such problems likely requires investigation and debugging by server administrators, or the site may work again at a later time. Exceptions are client networking errors, particularly if the service works for other visitors, and if clients use VPNs or other custom networking setups. In such cases, clients should check network settings, firewall setup, proxy settings, DNS configuration, etc."
But there are other possibilities:
web server built and compiled with error;
customization on your web server;
Server configured with low resources;
Kernel customized/compiled with error;
etc.
Ideally, you should also check your log /var/log/messages around that time.
