Suspicious domains in the Host Database

[quietFinn]

I also noticed that the "Normal Shell" tick is enabled by default for the newly created user. While in "Feature Manager", "SSH Access & Terminal" option is not enabled.

That is normal in CloudLinux server, read here:

Why CageFS installation changes jailshell to regular bash on cPanel?

During CageFS package installation or update, all users with jailshell enabled will have it changed to regular /bin/bash in /etc/passwd . This is done to avoid possible conflict with virtfs when no...

cloudlinux.zendesk.com

 

[NabiKAZ]

That is normal in CloudLinux server, read here:

Why CageFS installation changes jailshell to regular bash on cPanel?

During CageFS package installation or update, all users with jailshell enabled will have it changed to regular /bin/bash in /etc/passwd . This is done to avoid possible conflict with virtfs when no...

cloudlinux.zendesk.com

Thanks, but according to this quote at the same link:

During CageFS package installation or update, all users with jailshell enabled will have it changed to regular / bin / bash in / etc / passwd .

Said "all users with jailshell enabled will have it changed to regular /bin/bash" And not all users whose shells are disabled.

And also even when I disabled the CageFS in Cpanel. New user created, Normal Shell access enabled!

 

[cPRex]

If you've already confirmed the server is compromised and there are odd files across multiple accounts, there isn't really a point in doing any other troubleshooting. You'll want to get the accounts migrated to a new machine to eliminate the compromise.

 

[NabiKAZ]

If you've already confirmed the server is compromised and there are odd files across multiple accounts, there isn't really a point in doing any other troubleshooting. You'll want to get the accounts migrated to a new machine to eliminate the compromise.

But I do not think this solution will be useful, because by transferring accounts, malicious files are also transferred to the new server.

 

[ejsolutions]

.. by transferring accounts, malicious files are also transferred to the new server.

Not necessarily an issue, IF you bolster the security on the server PRIOR to transferring the accounts. Jailed accounts should mean that even if an account is compromised, it will not traverse accounts nor corrupt the server. (That's the whole purpose of Jailing accounts) This should buy you time to further investigate where the hack occurred.
If you should get hacked again, then I'd go knocking on the door of Cloudlinux - it's what you pay them for.
just my opinion on the matter.

 

[cPRex]

If there are files at the account level causing an issue, those would be transferred to the new machine. We always recommend performing a transfer when there is a root compromise since there is no way to ensure a system is secured after malicious root access.

As @ejsolutions said, keeping the accounts jailed with CloudLinux should keep any compromises from infecting other accounts on the machine.

 

[NabiKAZ]

According to your suggestion and friends above.

1. full backup from all accounts by cpanel.
2. back up system files by cpanel.
3. format disk.
4. install CloudLinux 8 & cpanel
5. restore accounts.

Is this roadmap approved?
Given that I now have cloudlinux 7.
Also I have more doubts about option 3 in terms of security.

 

[cPRex]

That seems like a lot of work and isn't the way I would do things. I would just create a new machine and transfer the data over with the WHM >> Transfer Tool.

 

[ejsolutions]

I'd do a full fdisk (clearing filesystem signatures) and LVM remap, rather than just a format. If you go the same server approach.
Also, add CSF and mod_sec, plus run the two security advisors on the server, before account restores. That takes me about a full days work to do!
As per @cPRex a 'fresh' server is best, so that other accounts aren't down during the course of a build/rebuild.

Note: I tried CL8 during a recent update and had to revert back to CL7 - numerous niggly problems that I didn't have the time/energy to resolve.

 

[NabiKAZ]

That seems like a lot of work and isn't the way I would do things. I would just create a new machine and transfer the data over with the WHM >> Transfer Tool.

I know about the Transfer Tool and I can consider a new disk but it is not interesting since I have to consider a new IP with a new CPanel license.
I know my method is down time but it is not a problem and I do it in low traffic time.

Now the question I have is that to transfer the settings and configuration of the server, if I use the "Backup Configuration > Back up System Files" CPanel, will the malicious files with them not be transferred to the new server?

 

[NabiKAZ]

And I have another question, is there a special type of configuration in Cpanel that works with PHP with access level USER:USER and 0755 on public_html and sets this access itself?

 

[ejsolutions]

Backup Configuration > Back up System Files

Personally, I wouldn't do this (for your reasons) and instead perhaps screenshot the important settings, or otherwise take a note. Also, you may inherit deprecated settings - best to use 'vanilla' settings then add flavouring.

USER:USER and 0755 on public_html

This is standard fare on my WHM/cpanel setups and indeed on other servers, with different control panels. Refer to mod_suexec, suPHP (preferably PHP-FPM).

 

[NabiKAZ]

I scanned all the servers except the /home path that contained the accounts with clamscan and the result was as follows:

Do you think there is something more suspicious than the others that I need to put under a magnifying glass?

/usr/local/src/maldetect-current.tar.gz: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/clean/gzbase64.inject.unclassed: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/src/maldetect-1.6.4/files/sigs/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/cpanel/3rdparty/share/clamav/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/cpanel/3rdparty/share/clamav/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/cpanel/3rdparty/share/clamav/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/cpanel/Whostmgr/Pkgacct/3rdparty/mbx2mbox/mailutil: Unix.Tool.Flood-9941210-0 FOUND
/usr/local/maldetect/clean/gzbase64.inject.unclassed: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/hex.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/md5v2.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/local/maldetect/sigs.old/md5.dat: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share/clamav/rfxn.ndb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share/clamav/rfxn.hdb: YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share/clamav/rfxn.yara: {HEX}php.gzbase64.inject.452.UNOFFICIAL FOUND
/usr/share/cagefs-skeleton/usr/local/cpanel/Whostmgr/Pkgacct/3rdparty/mbx2mbox/mailutil: Unix.Tool.Flood-9941210-0 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 8635509
Engine version: 0.104.3
Scanned directories: 96587
Scanned files: 488074
Infected files: 102
Total errors: 16157
Data scanned: 25927.35 MB
Data read: 80705.52 MB (ratio 0.32:1)
Time: 34490.078 sec (574 m 50 s)
Start Date: 2022:06:24 22:27:27
End Date:   2022:06:25 08:02:17

 

[ejsolutions]

^ A quick glance and they look like false positives. Good on you for using maldetect though.
Personally, I wouldn't "risk it for biscuit" and wouldn't waste time: go straight for a freshly installed server, prepared as mentioned, then restore user accounts.
You could've had it completed by now!

 

[Michael-Inet]

Do you think there is something more suspicious than the others that I need to put under a magnifying glass?

NabiKAZ,

Since we had similar issues, I'm guessing you installed a "shared cPanel" license. The website I purchased one from implied they were a cPanel partner and authorized to sell 'legal' shared licenses. After this thread I did some digging and found out that, that is most likely not the case and "shared cPanel" licenses are a hack and apparently just stealing from cPanel though some proxy mechanism. They also are suppose to give complete root access to your box to the shared license seller. (Which would make sense as you run an install script from then as root to setup the proxy 'stuff.')

As I had no client data on the box (testing server), my method was to re-install from scratch and manually re-create the account(s).

If there had been client data, I would have offsite backed up just the client data. Rebuilt the server, manually re-created the accounts/domains, and then moved the client data back to where is should be.

HTH,
Michael

tag

@cPRex, PM me if you want the website I purchased from.

 

[NabiKAZ]

I came across another security point.
I installed only nginx on another clean centos7 server (without Cloudlinux) with cpanel:
Home / Software / NGINX® Manager / Install NginX
I noticed that the access level of all accounts to USER:USER 0755 changed and there was access to another account from each account.
If you uninstall nginx and click install again, the same thing will happen again.
It does not seem normal to make such unsafe and dangerous settings by default. And it can be a dangerous bug. Maybe I got hit from here!