LinuxHostingSupport

If your emails are bouncing back and IP is getting blacklisted, it is clear your server is used for spamming purpose. To find out if spam emails are sent using a PHP script OR by a client, refer

How to find a Spammer on a Plesk Server?

Sometimes email accounts are hacked and are used for sending spam email. The header of such emails contain “Network” in the received line instead of the UID of the domain.

Below we will see how to trace such accounts.

Now, read the mail queue and you will notice, large number of emails are sent to strange email accounts

# /var/qmail/bin/qmail-qread
 1 Jan 2013 01:50:32 GMT  #768553  1214
        remote  someone@domain1.com
        remote  someone123@domain1.com
        remote  someone@domain2.com
        remote  someone123@domain2.com
        ****list continue...****

Now you need to find out the IP that is sending the emails, so use QmHandle tool to read the message header by passing the message ID to it (in above case its “768553”)

# qmHandle -m768553 | less
 Received: (qmail 20390 invoked from network); 1 Jan 2013 01:50:32
 Received: from unknown (HELO User) (1.1.1.1)

This email is invoked from ‘Network’ and the offending IP is 1.1.1.1. Now, search the IP in the server logs i.e. /var/log/messages

# grep 1.1.1.1 /var/log/messages
 Jan  1 12:12:00 smtp_auth: SMTP connect from unknown@ [1.1.1.1]
 Jan  1 12:12:00 smtp_auth: smtp_auth: SMTP user [USER] :
 /var/qmail/mailnames/[DOMAIN]/[USER] logged in from unknown@ [1.1.1.1]

As you can see above, the logs will display the email account accessed by the hacker from IP 1.1.1.1.

Now let’s take a look at the password of the email account we found in the above logs

# /usr/local/psa/admin/bin/mail_auth_view | grep user@domain
 +--------------+--------+------------+
 |    address   |  flags |  password  |
 +--------------+--------+------------+
 |  user@domain |        |   qazxsw   |
 +--------------+--------+------------+

The password isn’t great and no wonder why the email account is compromised.

Now, change the password of the email account from Plesk, restart the IMAP server and monitor the server logs to see the difference

# tail -f /var/log/messages | grep grep 1.1.1.1
 Jan  1 12:20:08 smtp_auth: SMTP connect from unknown@ [1.1.1.1]
 Jan  1 12:20:08 smtp_auth: FAILED: [USER] - password incorrect
 from unknown@ [1.1.1.1]

As you can see above, the hacker from IP 1.1.1.1 can no longer access the email account.

Here are Various ways to find a Spammer on a Plesk server.

If emails are sent using a PHP script on a Plesk server, there are following 2 ways to determine the PHP script.

1) The following command will display the PHP scripts running in real-time. You have to execute the below script at the time the emails are been sent from your server rapidly.

Execute the below command as it is:

# lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk \
 ' { if(!str) { str=$1 } else { str=str","$1}}END{print str}'` \
 | grep vhosts | grep php

This will continuously display the path to the PHP files as they will be accessed and executed.

2) This method is used when you are not around and still wanted to trace the folder or the domain of the PHP script that is sending emails is running from.

a) Create a /var/qmail/bin/sendmail-wrapper file with the following contents

#!/bin/sh
 (echo X-Additional-Header: $PWD ;cat) | tee -a /var/tmp/mail.send \
|/var/qmail/bin/sendmail-qmail "$@"

Grant executable permission on the sendmail wrapper and replace it with the old sendmail file of Qmail as stated below:

# chmod a+x /var/qmail/bin/sendmail-wrapper
# mv /var/qmail/bin/sendmail /var/qmail/bin/sendmail-qmail
# ln -s /var/qmail/bin/sendmail-wrapper /var/qmail/bin/sendmail

b) Create a log file /tmp/mail.send and grant read/write permissions to all.

# touch /var/tmp/mail.send
# chmod a+rw /var/tmp/mail.send

c) Wait for a few hours and revert back the sendmail files

# rm -f /var/qmail/bin/sendmail
# ln -s /var/qmail/bin/sendmail-qmail /var/qmail/bin/sendmail

then go through the log file /tmp/mail.send. The log file contains “X-Additional-Header” lines that will display the path to the folder name the PHP scripts are residing in. Example:

X-Additional-Header: /home/vhosts/domain1.com

To locate all the domains the PHP scripts that are sending emails are residing in, execute:

# grep X-Additional /var/tmp/mail.send | grep \
 `cat /etc/psa/psa.conf | grep HTTPD_VHOSTS_D \
 | sed -e 's/HTTPD_VHOSTS_D//' `

If no script is listed, it means mail() php function was not used to send emails.

If you feel emails are saturated in the Plesk Qmail mail queue, there is a possibility that your Plesk server is been used for sending spam emails.

On a Plesk server relaying is not allowed by default so following are the ways spamming is mostly done. They are explained below point wise.

1) Using CGI by a user
2) PHP scripts. Also refer the article to locate the directories of the PHP scripts that are sending emails.
3) By a compromised email account

First, lets look at the the mail queue

# /var/qmail/bin/qmail-qstat
messages in queue: 22507
messages in queue but not yet preprocessed: 0

As you can see above, there are a large amount of emails in the mail queue. The source of these emails could either be a PHP/CGI script OR an authorized email account on the server.

Let’s start with reading the message headers with ‘qmail-qread’

# /var/qmail/bin/qmail-qread
5 Nov 2012 11:50:17 GMT #768752 1231 
remote user1@domain1.com
remote user2@domain1.com
remote user1@domain2.com

This will list the sender and recipient of all the emails in the mail queue.

In the above example #768752 is the message ID, now find out the location of this email to read the complete header

# find /var/qmail/queue/mess/ -name 768752
/var/qmail/queue/mess/0/768752

Above is the complete path to the mail file, now open the file and look for the “Received” line.

# cat /var/qmail/queue/mess/0/768752 | more

The “Received” line indicates from where the message was received OR invoked.

1) If the message is sent via CGI by a user, it will display the UID of the user as below:

Received: (qmail 26193 invoked by uid 10001); 5 Nov 2012 11:50:17

Now, search the UID 10001 in the passwd file to find the domain name

# grep 10001 /etc/passwd

This will display the domain name the UID 10001 belongs to.

2) The “Received” line indicates the UID of user Apache (i.e. 48)  if email is sent via a PHP script

Received: (qmail 26193 invoked by uid 48); 5 Nov 2012 11:50:17 +000

In such a case, you have to monitor the PHP scripts in real-time i.e. scripts that are running when emails are been sent.

Execute the below command as it is when the mail queue is growing rapidly

# lsof +r 1 -p `ps axww | grep httpd | grep -v grep | \
awk ' { if(!str) { str=$1 } else { str=str","$1}}END{print str}'` \
| grep vhosts | grep php

The above command won’t display the location of the php scripts, so please refer the article to locate the folders of the PHP scripts that are sending emails.

3) Many a time email accounts are compromised and used for sending bulk/spam emails from other locations. In such a case, “Received” line contains “invoked from network”

Received: (qmail 26193 invoked from network); 5 Nov 2012 11:50:17

Refer the article to find the compromised email accounts on a Plesk server.

If you upgrade the Plesk control panel, the Atmail webmail client will display the “/etc/psa-webmail/atmail/.atmail.shadow open_basedir restriction” error message while accessing Atmail. The complete error message looks like follows:

Warning: fopen [function.fopen]: open_basedir restriction in effect.
File(/etc/psa-webmail/atmail/.atmail.shadow) is not within allowed
path(s): (/var/www/atmail:/var/log/atmail:/etc/psa:/tmp:/var/tmp)
in /var/www/atmail/libs/Atmail/Config.php on line 4

The error occurs when PHP is not allowed to access the /etc/psa-webmail/atmail/ directory due to open_basedir restriction in effect and thus any request to the /etc/psa-webmail/atmail/.atmail.shadow file is blocked by PHP.

The restriction is in place in the atmail configuration file located at /etc/httpd/conf.d/zzz_atmail_vhost.conf. To allow PHP to access the /etc/psa-webmail/atmail/ directory, open the Atmail configuration file

# nano /etc/httpd/conf.d/zzz_atmail_vhost.conf

look for the lines that state (there are 2 lines):

php_admin_value open_basedir "/var/www/atmail:/var/log/atmail:
/etc/psa:/tmp:/var/tmp"

and add the atmail directory at the end so the lines look like follows:

php_admin_value open_basedir "/var/www/atmail:/var/log/atmail:
/etc/psa:/tmp:/var/tmp:/etc/psa-webmail/atmail"

Save the file and restart the httpd service

# service httpd restart

PHP will now be able to access the atmail directory and Atmail webmail client will work without problems.

You may come across an error “Unable to install plesk-core-10.8.0-cos5.build package” while upgrading Plesk to 10.x on a CentOS server. The complete error message is as follows:

Error: Unable to install "plesk-core-10.8.0-cos5.build.13.x86_64"
package. Not all packages were installed.
Please, contact product technical support.

The error message does not indicate whether there is a conflicting or a missing package. However, Plesk stores detailed installation and upgrade logs in the /tmp/autoinstaller3.log file.

Open the file and scroll down to where it starts displaying error messages and you will notice something as follows:

The requested package "plesk-core" could not be installed.
Searching problems for the "plesk-core" package.
No suitable solutions were found for the "bind-utils" dependency.
The "bind-utils-30:9.3.6.x86_64" package resolves "bind-utils".

The “bind-utils dependency” error while upgrading Plesk indicates that the bind-utils and bind-libs versions installed by CentOS 5.x is greater than what is supported by Plesk.

To resolve the issue, you need to search and remove the bind-utils and bind-libs packages.

# rpm -qa | grep bind-*
# rpm -e --nodeps bind-utils bind-libs

Now run the Plesk autoinstaller again

# /usr/local/psa/admin/bin/autoinstaller

The Plesk autoinstaller will install the bind packages that is supported by Plesk and the upgrade will go through successfully.