UKC

Where is the Plesk maillog located?

Re: Where can I find the mail log in Plesk?

The mail logs in Plesk qmail are stored here:

/usr/local/psa/var/log/maillog

You can view the entire maillog like this:

# cat /usr/local/psa/var/log/maillog

Or you can look at the last 150 lines like this:

# tail -150 /usr/local/psa/var/log/maillog

You can watch the maillog devlop in real time like this:

# tail -f /usr/local/psa/var/log/maillog

You can search for specific entries like this:

# tail -500 /usr/local/psa/var/log/maillog | grep test@domain.co.uk

The Plesk maillog is your friend when it comes to finding spammers and email problems on your server.

How do I find the SPAM source on a Plesk server using qmail?

Re: Finding spammers in Plesk, find source of spam on Plesk server

If you are hosting a Plesk server wilth multiple sites then eventually you will find that spam will appear from one of those sites and it will be difficult to determine where the spam is coming from. This will put your server IP at risk of being suspended by your server provider.

First things first, let’s check to see if the spam is being sent by a mailbox user, this would indicate deliberate spamming from a client or a compromised password on a mailbox account.

Out of the ordinary authentications

A large number of authentications to a particular mailbox, ie. thousands, can indicate massive email activity, you can check this quickly as follows:

# cat /usr/local/psa/var/log/maillog |grep -I "LOGIN"|awk {'print $12'}|sort|uniq -c|sort -n

If you cannot see anything out of the ordinary, the search continues.

The Maillog is your friend

Let’s take a look at the plesk qmail maillog:

# tail -500 /usr/local/psa/var/log/maillog

Entries like the following indicate the domain and mailbox that the email is being sent from:

Dec  7 10:51:01 server qmail-local-handlers[29265]: from=info@spammerdomain.com

This leaves you no further work to do, possibly suspend the account and contact the client in question. You might want to clear the mail queue in the Plesk panel also.

Difficult to locate spammers

A more difficult situation is where the email is being sent using the Apache user or as anonymous. This type of email spam cannot so easily be traced to a sender as it is not being sent from a mailbox.

These entries look something like this:

Dec  7 10:50:17 server qmail-queue-handlers[29080]: from=anonymous@server.hostname.com

Or like this:

Dec  7 10:50:17 server qmail: 1323255017.404624 info msg 47220220: bytes 501 from <anonymous@server.hostname.com> qp 29081 uid 48

It is not possible to determine the spammer from the maillog in this situation. These emails are being sent using a form processor or other PHP mailer / PERL mailer script.

Track, Trace and Remove

To solve this problem you need to

  • Login to the Plesk Control Panel > Home > Mail Settings > Mail Queue
  • Click on one of the many SPAM emails you will see listed

Look for this at the top of the mail header:

Received: (qmail 2583 invoked by uid 10211)

Once you have the UID (which in this case in 10211) you can now trace the client like this:

# grep 10211 /etc/passwd

Which will show something like this:

dom74628:x:10211:2523::/var/www/vhosts/thespammerdomain.com:/bin/false

You can now proceed suspend the spam account and remove all the mails from the mail queue.

How do I use iptables to route to another port?

You can use iptables pre-routing to route from one port to another.

For example, the following command will enable mail users to use port 26 or port 25 for SMTP request. All port 26 requests will be routed to port 25.

# iptables -t nat -A PREROUTING -p tcp -d 192.168.167.2 --dport 26 -j DNAT --to 192.168.167.2:25

Now your clients can use port 26 or port 25 without any problems.

7 Easy Ways to Secure WordPress

WordPress is an excellent application used the world over. This unfortunately makes it also a target for hackers. There are some very simple steps you can take, completely non-technical, that can help secure your WordPress blog.

1. First things first. Eliminate all known vulnerabilities. Now.

Update your WordPress installation to the latest version. This is the absolute most important and most effective first step. Do it now.

2. Don’t make your WordPress blog so easy to target

Install WordPress in a folder rather than document root, this makes it slightly more difficult for large scale hackers to find your system files. There are so many root installations of WordPress to keep hackers busy that the effort returned finding sub folders is not usually worth it.

3. Do not delete the admin account. Yes, you read it correctly.

So we need to secure admin, do this by creating a new administrative user, then downgrade the admin account to subscriber. This will make it impossible for a hacker to administrate your site using admin. By not deleting the admin account the hacker is kept busy trying to guess the password and the focus is away from the ‘real’ administrator account.

4. Control failed login attempts.

Lock the account after a number of failed attempts. This will render dictionary attacks on your account pointless for the hackers. Use a plugin such as Login LockDown to control failed log in attempts.

5. Implement easy eveyday plugin security

Use some WordPress security plugins such as Stealth login, AskApache password protect and WP security scan.

6. If they get in – don’t let them take you out

Take regular backups. Should a hacker gain access at least you don’t permanently lose your site. You will be able to restore, tighten up and continue. Don’t let them take you out!

7. Honestly, this is the step that is most often ignored

Have an absolutely ridiculously difficult to guess password. Have some numbers, uppercase and lowercase letters and maybe a punctuation mark or two. They’ll never guess it – maybe not even with a quantum computer.

Security is an ongoing job, it is never complete. There are other ways using file permissions,  .htaccess with IP restrictions that can further secure your blog but these are a little more technical. So, be on the look out for part 2.
We hope you enjoyed this article and found the information useful. Happy blogging!

How to setup a PHP Cron job or scheduled task in Plesk

Re: Set up a cron job in Plesk, Plesk crontab, Create a PHP cron job in Plesk

Setting up a cron task or scheduled job within Plesk is a piece of cake – once you know how.

First, find your way in to the Plesk Control Panel and hit the “Scheduled Tasks” button, then “Schedule New Task”. The example below will show a working task executing a PHP file named cronjob.php located in /httpdocs (your document root) at 01:00 every morning of every day:

The form looks pretty straight forward however there are some points to note.

  • If you want to run every hour, put an asterisk “*” in the Hour field
  • If you want to run every day, put an asterisk “*” in the Day of Month field
  • If you want to run every month, put an asterisk “*” in the Month field
  • If you want to run everyday, put an asterisk “*” in the Day of Week field

If you have problems, check your asterisks are in the right places and that you cron PHP file is in the right location. Compare the schedule task dialogue boxes carefully and you won’t have any problems.