Category Archives: cPanel/WHM

cPanel error – Not able to change the shell for a user ?

When trying to change the shell access for a user from WHM, do you face the following issue ?

Screenshot from 2014-07-15 11:50:26

 

– Even when trying to change the setting via back-end, you might face the issue :

# chsh -s /bin/bash x
Changing shell for x
setpwnam: File exists
Shell *NOT* changed.  Try again later.

– The above error indicate that there is a lock on the file  /etc/passwd Deleting /etc/ptmp will fix this issue.

# rm /etc/ptmp

 

cPanel – Your RPM database appears unstable !

There is a common issue with cPanel when trying to force an update.

You might get an error message which looks like :

“fatal: Your RPM database appears unstable. It is not possible at the moment to install a simple RPM”

– RPM database gets corrupted over a while,  hence preventing cP from updating.

– Give in the following, to fix this issue :

# mkdir /root/old_rpm_dbs/
# mv /var/lib/rpm/__db* /root/old_rpm_dbs/
# rpm --rebuilddb ( rebuilds the RPM database )
# /scripts/upcp  ( cPanel update )

Issue with exim – Permission denied seen in logs ?

Trouble sending mails from a cPanel – server and you end up checking  /var/log/exim_mainlog and able to spot something like  this ?

Date H=(xxxx-xxx-xxx-xx-xx-co.in) [xx.xx.xx.xx]:xxxxxF= temporarily rejected RCPT : require_files: error for /home/x.com/etc/x.com: Permission denied

This happens when the  permission or ownership has been altered for the given mailbox.

Fix this issue by :

/scripts/mailperm 'account-name'

FTP error – cPanel !

– When trying to FTP, do you face this error ?

Status: Resolving address of xxxxxxxxxxxxxxx.com
Status: Connecting to xx.xx.xx.xx:21…

Status: Connection established, waiting for welcome message… Response: 421 Too many connections (x) from this IP(x)

-As the logs indicate, the limit for connections from the IP you are trying to login has reached its maximum value.

– Increase this from the configuration file, the value ‘MaxClientsPerIP‘     ( pure-ftp ) or ‘MaxClientsPerHost‘ ( pro-ftpd )  and restart the service.

Alternatively, you can also terminate the existing connections from the IP, if they are not in use.

# netstat -plan | grep :21 | grep 'IP'
# kill -9 PID ( <- kill the corresponding process )

SymLinks Attacks and prevention !

The vulnerability with Symlinks and Apache is a known cause of attack.

Initially, the attacker will find a compromised ‘single’ website or domain which has got any vulnerable scripts or 3rd party applications or any themes used in it and try to get access to the files.

Once he get access to a single domain, he moves forward by creating the symlinks to other websites or even he can symlink to / (root).

For eg, if you have the following symlink set in any domain,

link -> /root , using the directory ‘link’ anyone can actually access /root and can access any sensitive file.

Rather than manually creating this sort of symlinks, the hacker can even use any perl/cgi script to create a symlink to other users of the server.

As a basic solution for this, you can ensure that Apache is configured in a way so as not to following symlinks (Options -FollowSymLinks)

— To disable the ability for Apache to allow users to follow symbolic links in their requests, remove the FollowSymLinks directive on your Directory commands.

For example, if the below was the configuration then,

<Directory "/usr/local/apache/htdocs">
Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all

Remove the FollowSymLinks reference so that this reads:

<Directory "/usr/local/apache/htdocs">
Options Indexes
AllowOverrride None
Order allow,deny
Allow from all

If you really need symlinks, you can use the“SymLinksIfOwnerMatch” option to only allow links from within the same user.

To prevent PHP from accessing any file outside of their directory, you need to specify the ‘open_basedir’ setting ( in PHP configuration file ) to only have access to their directory.

This option can be enabled from WHM. You might face the following error :

This security tweak uses Apache DSO style directives. If PHP is configured to run as a CGI, SuPHP or FastCGI process, the open_basedir setting must be manually specified in the relevant php.ini file. See the EasyApache documentation for more information.

– If the PHP handler is set as CGI or SuPHP, then tweak settings seen in WHM cannot be used to set the openbase_dir option.

– You need to manually specify the openbase_dir option in the global
PHP configuration file ( use php -i |grep php.ini to find the php.ini location )

Keep in mind, the root cause for this attack or vulnerability is due any unsecured scripts/plugins/applications which might be employed in any of the domains. So, keep you server free from it, in the first place 😀

cPanel – Chkservd : Exim failure messages !

– You might be getting alerts from chkservd claiming that your
IMAP/exim is getting failed and is being restarted automatically
by chkservd.

Although you might not be experiencing any real time
issue with mail delivery or logging in, something would be wrong
and as a result, you are getting this alert.

– Check /var/log/chkservd.log and see if something similar to the
following is present :

> AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxx

<< 421 host.xxxx.com Service not available - closing connection
exim: ** [421 host.xxxx.com: Service not available - closing connection != 2]

– This indicates that the check daemon is not able to authenticate
with the temporal exim-auth-key and therefore negative result is obtained which is forcing chkservd to restart the services in a hope
for fixing it.

– To fix this, regenerate the keys

# cd /var/cpanel/serviceauth/
# rm -rf exim
# service cpanel restart
# service exim restart

This should correct the issue.

Issue with clamd after the latest cPanel update ( 11.44.x )

After the recent update of cPanel to 11.44.x, most of the users are able to see that clamd is getting hung and consuming the server resources excessively.

On checking the processes running, we can see that clamav-cpanel plugin is consuming a lot of resources scanning the file /etc/password and spawning them without terminating.

 

Part of # top -c will show the following :

=========================

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7761 root 25 0 35872 1704 1312 R 27.3 0.2 11:47.14 /usr/local/cpanel/3rdparty/bin/clamdscan --quiet --no-summary /etc/passwd


9714 root 25 0 35872 1708 1312 R 25.4 0.2 0:09.75 /usr/local/cpanel/3rdparty/bin/clamdscan –quiet –no-summary /etc/passwd


5982 root 25 0 35872 1704 1312 R 23.4 0.2 22:39.74 /usr/local/cpanel/3rdparty/bin/clamdscan –quiet –no-summary /etc/passwd

……

========================

Even if you kill the service, the issue reproduces after a while. As of now, cPanel is yet to release a fix for this bug. 

As a temporary fix, you can try the following :

===================

# Remove the clamAV plugin from WHM ( Home »cPanel »Manage Plugins ) – Uninstall it

# Update cPanel from backend ( # /scripts/upcp --force )

# Re-install the plugin ( Home »cPanel »Manage Plugins ) – Install it

===================

This seems to have cleared the issue for the ones which faced this bug. Give it a try !

How can I secure my mail service – cPanel

Mail servers are exploited a lot these days to flood out spam mails from the ones which have been compromised.

Securing your mail service is very much important. There are some tweaks which can be carried out from WHM panel.

–> In Home >> Server Configuration >> Tweak Settings

Prevent “nobody” from sending mail – This will ensure that PHP
scripts running under the ownership ‘nobody’ will not be able to send mails. Most of the times, any of the vulnerable PHP script will be the culprit for sending out spams from your account.

Restrict outgoing SMTP to root, exim, and mailman – This prevents users from bypassing your mail server to send mail. Only the ones mentioned here are authorized to connect to remote SMTP servers.

// If you get an error while trying to enable SMTP restrictions, then you probably are missing an iptables module required for the proper functioning. Ask your provider to enable it for you, or if you have the ways to do it, give-in the following :

modprobe ipt_owner

// 

–> In Home >> Service Configuration >> Service Manager,  you can find the option Antirelayd. Keep this disabled, so that each time POP3 connects authentication would be required.

–> If you are facing any issues related to IMAP getting restarted numerous times,  check

# grep 'LOGIN FAILED' /var/log/maillog|awk '{print $9}'|sort|uniq -c | sort -n

to see if you have many authentication failures from any IPs.  If so, your account is being brute-force attacked. Block the offending IPs in your server firewall.

–> Use secure passwords for your email accounts. Check out the various domains and make sure there are no test accounts created. Under normal cases, test email accounts are created with insecure passwords, which can easily be guessed by the attacker.

Issue with dovecot.index file

A recent & common issue faced with dovecot service in cPanel based server’s is the corruption of dovecot.index files for the email accounts. When the index file is broken, the respective user facing this issue will not be able to login to his webmail and will throw up a ‘server error’. The basic idea behind Dovecot’s index files is that it makes reading the mailboxes a lot faster.

Checking the logs to confirm its the issue with dovecot.index file :

# tailf /var/log/maillog

###################################

host dovecot: imap(zzzz@yyyy.com): Error: Transaction log file /pathto/dovecot.index.log seq 302: log_file_tail_offset update shrank it (988 vs 1184 sync_offset=972)

host dovecot: imap(zzzz@yyyy.com): Error: broken sync positions in index file /pathto/dovecot.index

host dovecot: imap(zzzz@yyyy.com) Error: Fixed index file /pathto/dovecot.index log_file_tail_offset 1184 -> 988

###################################

The solution to fix this issue is to delete the dovecot.index file for the respective user and for the respective folder.

# rm -rf /path-to-the-/dovecot.index

If you find that this file is broken for the folder ‘Trash’, then do delete the index file which is found in Trash. This happens to be a long term bug with dovecot and deleting the index file and recreating ( automatically done by dovecot) is the only solution at this juncture.