How to clear or disable eximstats on cPanel

What is eximstats

Eximstats, on WHM/cPanel servers, is used to maintain statistics and information about email messages processed by Exim mail service.

If the data in it is not cleared often enough it can grow, and cause issues with disk space, or MySQL resource usage, as the size of the database can cause higher memory and disk consumption.

Disabling eximstats

If you do not have any need for Exim statistics, which are used for Mail Delivery Reports on  Home »Email »Mail Delivery Reports, gathering exim statistics can be disabled from WHM or command line.

In WHM it can be disabled by going to Home »Service Configuration »Service Manager, and unchecking the service, and then clicking on the Save button on the bottom.

This will stop the database from being populated with new data.

Eximstats in Service Manager
Service Manager

From command line, you can disable the database from being populated by running a following command:
/usr/local/cpanel/bin/tailwatchd --disable=Cpanel::TailWatch::Eximstats

Lowering Eximstats retention time

Database is periodically cleaned, and by default Exim stats are retained in database for 10 days, which can be changed in WHM by going to Home »Server Configuration »Tweak Settings and changing the “The interval, in days, to retain Exim stats in the database” setting on the “Stats and Logs” tab.

Setting can also be changed by altering the “exim_retention_days” value in “/var/cpanel/cpanel.config” file.

Empty eximstats database

Database can be cleared either by deleting from its four tables, defers, failures, sends and smtp, or by dropping the database completely, and creating a fresh one with empty tables from “/usr/local/cpanel/etc/eximstats_db.sql” file.

To delete all of the data from the tables following command can be used:

mysql -e "use eximstats;delete from defers;delete from failures;delete from sends;delete from smtp;delete from smtp;"

To drop the database and recreate it again, following commands can be used:

mysqladmin drop eximstats
mysqladmin create eximstats
mysql eximstats < /usr/local/cpanel/etc/eximstats_db.sql
References:

https://forums.cpanel.net/threads/problem-in-eximstats.363382/

https://confluence2.cpanel.net/display/ALD/Service+Manager#ServiceManager-tailwatchd(TailWatchDrivers)

https://documentation.cpanel.net/display/ALD/Tweak+Settings+-+Stats+and+Logs#TweakSettings-StatsandLogs-Theinterval,indays,toretainEximstatsinthedatabase

Yum and curl returning “Illegal instruction (core dumped)” on Xen

When running yum or curl commands on a CentOS 6 XenServer Virtual Machine you might be getting an “Illegal instruction (core dumped)” error returned in your console output.

[email protected] [~]# yum update
Loaded plugins: fastestmirror, rhnplugin
Setting up Update Process
Loading mirror speeds from cached hostfile
 * base: mirror.us.leaseweb.net
 * cloudlinux-x86_64-server-6: xmlrpc.cln.cloudlinux.com
 * extras: mirror.teklinks.com
 * updates: mirror.teklinks.com
Illegal instruction (core dumped)

The issue is due to Python attempting to execute a CPU opcode advertised as available by the server’s host node virtualization system (XEN), but is not actually supported by the host node’s hardware.

Workaround

Issue can be resolved by running export NSS_DISABLE_HW_AES=1, and then running yum update, to update to newer packages, after which issue should not be happening anymore.

[email protected] [~]# export NSS_DISABLE_HW_AES=1
[email protected] [~]# yum -y update
References:

https://www.centos.org/forums/viewtopic.php?t=58002

https://forums.cpanel.net/threads/kvm-xen-hw_aes-detection-issues-yum-update-illegal-instruction.551681/

How to check for, and clean Ebury SSH Rootkit

What is Ebury

Ebury is a SSH Rootkit, and password sniffer which steals SSH login credentials from incoming and outgoing SSH connections, and also steals private SSH keys stored on the infected system.

Ebury can replace SSH binaries, and shared library files used by executables like sshd, wget, curl, …

How to detect Ebury on a system

From version 1.5 Ebury uses Unix domain sockets for interprocess communication.

Malicious process can be seen using netstat -plan | grep atd.

This command should not return any results on clean systems.

[email protected] [~]# netstat -plan | grep atd 
unix 2 [ ACC ] STREAM LISTENING 103713 8119/atd @/tmp/dbus-ZP7tFO4xsL

Atd should not be listening on any network port or socket.

Ebury will also place additional shared library files, and patch installed libkeyutils file to link to those files.

Files usually found on Ebury infected machines can be one or more of the following:

/lib64/tls/libkeyutils.so.1.5
/lib64/tls/libkeyutils.so.1
/lib64/libns2.so
/lib64/libns5.so
/lib64/libkeyutils.so.1.3
/lib64/libpw3.so

If any of those files exist, check if the files were provided by any rpm using rpm -qf command.

[email protected] [~]# rpm -qf /lib64/tls/libkeyutils.so.1.5
file /lib64/tls/libkeyutils.so.1.5 is not owned by any package

On clean system command should return the name of the rpm package which installed that file.

[email protected] [/lib]# rpm -qf libkeyutils.so.1.3
keyutils-libs-1.4-5.el6.i686
Script to check for suspicious files, and processes

Here is a small script that can be used to check for possible Ebury infection.

#!/bin/bash

if [[ `netstat -pan | grep -w atd` ]]; then
    printf "This server appears to have atd process listening on Unix socket or network port\nCheck server for possible Ebury infection\n\n===\n`netstat -pan | grep -w atd`\n===\n\n"
fi

declare -a file_list=("/lib64/tls/libkeyutils.so.1.5" "/lib64/tls/libkeyutils.so.1" "/lib64/libns2.so" "/lib64/libns5.so" "/lib64/libkeyutils.so.1.3" "/lib64/libpw3.so"); 

for file in "${file_list[@]}"; do 
    if [[ -f $file ]]; then
        if [[ `rpm -qf $file` == *'not owned'* ]]; then
            printf "===\nFile $file is not owned by any RPM package, and there is a possible rootkit infection\nCheck server for possible Ebury infection\n===\n"
        fi
    fi
done

Save a script like check4ebury.sh on your system, and run with bash check4ebury.sh

On an infected system, command will return something like this:

[[email protected] ~]# bash /root/check4ebury.sh
This server appears to have atd process listening on Unix socket or network port
Check server for possible Ebury
infection

===
unix 2 [ ACC ] STREAM LISTENING 1278995234 127563/atd @/tmp/dbus-BmCahxCc3k
===

===
File /lib64/tls/libkeyutils.so.1.5 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
===
File /lib64/tls/libkeyutils.so.1 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
[[email protected] ~]#

NOTE: Suspicious processes and fileS might not be visible over SSH connections


Some variants of Ebury will hide suspicious processes and files, if you are checking the system over SSH connection (link).

In cases like that, checks will need to be done over local terminal, remote management console, or through screen session, for all processes and files to be visible.

If you are unable to connect to the server without SSH, install screen with yum -y install screen, and run check4ebury.sh from screen session, to double check for any possible infection.

In some cases when checks are done over SSH, you might be getting different result if you check for processes and files over screen session.

In this example script doesn’t return any signs of infection when run directly from SSH session, but shows running processes and files when run through a screen session.

[[email protected] ~]# /root/check4ebury.sh
[[email protected] ~]# screen -dmS ebury bash -c '/root/check4ebury.sh >> test'; sleep 30; cat test
This server appears to have atd process listening on Unix socket or network port
Check server for possible Ebury
infection

===
unix 2 [ ACC ] STREAM LISTENING 1278995234 127563/atd @/tmp/dbus-BmCahxCc3k
===

===
File /lib64/tls/libkeyutils.so.1.5 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
===
File /lib64/tls/libkeyutils.so.1 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
[[email protected] ~]#
How to clean Ebury infection

Most important thing to note is, that in case of root level infections like these ones, the only safe way is to do a complete server rebuild after you clean the infection, and make any necessary backups.

In order to clean Ebury infection, you need to kill the processes you found with netstat, remove suspicious library files, and reinstall keyutils-libs* rpm package. It would be also advisable to reinstall SSH packages.

Steps that can be taken to clean the system:

Check the actual keyutils-libs RPM packages you have installed on your system, and download them before removing any files from the system, as it is possible in some cases that some of the infected files are used by yum, curl, wget, and that you won’t be able to do install with yum after removing the files, or use curl, or wget to download RPMs for install.

  • Kill all SSH connections with killall sshd.
  • Kill the atd processes listening over Unix socket with kill -9 `lsof -Pt /usr/sbin/atd`.
  • Remove the suspicious files you found, that were not connected with any rpm package.
  • Reinstall keyutils-libs and SSH packages, preferably with rpm -ivh --replacefiles --replacepkgs on the predownloaded packages, but in most cases you can use yum:
    yum -y reinstall openssh* libssh* keyutils-libs*

After you have reinstalled necessary packages, change your root password, and all SSH keys on the server, and reboot the server to check if suspicious processes and files will return after it.

If possible, always do a full server rebuild, even if no signs of infection exist after reboot.

Avoid cleaning the infection over SSH connection

It would be advisable to kill all SSH connections that exist on the system you are about to clean, so you should be doing it while connected to the server some other way, but if you need to clean the server over SSH, a script like this can be used to accomplish that (you need to replace the files being referenced in the script, with the files you have found on your own system)

#!/bin/bash

killall sshd; 
kill -9 `lsof -Pt /usr/sbin/atd`; 
rm -f /lib64/tls/libkeyutils.so.1.5; 
rm -f /lib64/tls/libkeyutils.so.1; 
yum -y reinstall openssh* libssh* keyutils-libs*; 
service sshd start
References:

https://www.cert-bund.de/ebury-faq

https://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/

https://forums.cpanel.net/threads/ebury-rootkit-backdoor-trojan.396081/

https://documentation.cpanel.net/display/CKB/Determine+Your+System’s+Status

Fantastico returns error 404 when accessed from cPanel

When going to Fantastico De Luxe link in you cPanel under Paper Lantern theme, or some other theme you might get HTTP error 404 cPanel page shown, saying that requested page was not found.

 

Fantastico 404 page
Fantastico 404 page
Check your theme folder content for fantastico symlink

404 page will most likely be caused by the affected theme not having, a fantastico symlink, or symlink being misdirected.

Go to the folder of the theme, which in case of Paper Lantern theme will be /usr/local/cpanel/base/frontend/paper_lantern and check for file with name fantastico.

[email protected] [/usr/local/cpanel/base/frontend/paper_lantern]# ls -l | grep fantastico
[email protected] [/usr/local/cpanel/base/frontend/paper_lantern]#

Folder should have symlink in it, with name fantastico, pointing to /usr/local/cpanel/3rdparty/fantastico/, if the symlink is missing create one with ln -s command, also check if the file to which symlink is pointing is an existing file.

[email protected] [/usr/local/cpanel/base/frontend/paper_lantern]# ln -s /usr/local/cpanel/3rdparty/fantastico/ fantastico
[email protected] [/usr/local/cpanel/base/frontend/paper_lantern]# ls -l | grep fantastico
lrwxrwxrwx 1 root root 37 Mar 3 18:02 fantastico -> /usr/local/cpanel/3rdparty/fantastico/
[email protected] [/usr/local/cpanel/base/frontend/paper_lantern]#

After creating a needed symlink Fantastico De Luxe page should work as expected.

Reference:

http://legacy.netenberg.com/forum/index.php?topic=1942.0

CentOS 7 OpenVZ NetworkManager issues.

There is an issue with CentOS 7 containers on OpenVZ nodes, where NetworkManager service breaks the network, and only localhost 127.0.0.1 network interface is coming up.

When you try to check network interfaces, and IP address on the server, you will only see localhost interface.

[email protected] [/]# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 9059 bytes 1539654 (1.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9059 bytes 1539654 (1.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

When issuing service network restart you will and output like this:

Starting network (via systemctl): Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details.
[FAILED]

When you run journalctl -xe you will see errors like this:

-- Unit network.service has begun starting up.
 Feb 16 05:16:40 server network[2262]: Bringing up loopback interface: Could not load file '/etc/sysconfig/network-scripts/ifcfg-Feb 16 05:16:40 server network[2262]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
 Feb 16 05:16:40 server network[2262]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
 Feb 16 05:16:40 server network[2262]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
 Feb 16 05:16:40 server network[2262]: [ OK ]
 Feb 16 05:16:40 server network[2262]: Bringing up interface venet0: Error: Connection activation failed: No suitable device founFeb 16 05:16:40 server network[2262]: [FAILED]
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server network[2262]: RTNETLINK answers: File exists
 Feb 16 05:16:40 server systemd[1]: network.service: control process exited, code=exited status=1
 Feb 16 05:16:40 server systemd[1]: Failed to start LSB: Bring up/down networking.
 -- Subject: Unit network.service has failed
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 --
 -- Unit network.service has failed.
 --
 -- The result is failed.
 Feb 16 05:16:40 server systemd[1]: Unit network.service entered failed state.
 Feb 16 05:16:40 server systemd[1]: network.service failed.
 Feb 16 05:16:40 server polkitd[226]: Unregistered Authentication Agent for unix-process:2257:65393 (system bus name :1.37, object

Issue can be resolved by stopping and disabling the NetworkManager service.

[email protected] [/]# service NetworkManager stop
Redirecting to /bin/systemctl stop NetworkManager.service
[email protected] [/]# chkconfig NetworkManager off

You can also uninstall NetworkManager completely.

References:

https://lists.openvz.org/pipermail/users/2015-December/006691.html

Openvz / CentOS 7 – Network Manager can break networking