How to Hardening Exim in WHM

Exim Hardening Practices

The intention of this guide is to provide some steps to help tighten the email sending practices on a machine in order to facilitate both determining the legitimate sender of an email as well as preventing spoofing on the machine.

WHM Options to Enable

1. Preventing nobody from sending emails

WHM > Tweak Settings, select “On” for the following option:

Then click the “Save” button to save the configuration change.

If you are using DSO for the PHP handler, this option is not advised. You can see in WHM > Apache Configuration > PHP and SuExec Configuration area which PHP handler is being used on the machine.

The default handler for new cPanel installations would be suPHP, which would work for the above option. If you are using an older setup with DSO, it would be recommended to change to suPHP for better tracking on who is running PHP processes for scripts that send emails anyway.

2. Setting the Sender header when the email sender tries to spoof the sender

WHM > Exim Configuration, select the following:

Then click the “Save” button to save the configuration change.

3. Adding MailHeaders for PHP

WHM > EasyApache (Apache Update) > Step 6 Exhaustive Options List in the PHP section (PHP 4 and/or PHP 5), select the following:

For more information on this option, please see CHOON.NET : Resources : Scripts & Patches : PHP Mail Header Patch

Exim Configuration Changes

1. All logging for exim log file

WHM > Exim Configuration > Advanced Editor, add the following in the topmost box:

Code:
log_selector = +all

Then click the “Save” button to save this configuration change. This adds extra logging to /var/log/exim_mainlog on Linux (or /var/log/exim/mainlog on FreeBSD) such as subject and command path.

2. Stopping spoofing from webmail and SMTP authenticated users

WHM > Exim Configuration > Advanced Editor, add the following in the second box where it has begin acl directly above it:

Code:
acl_check_data:
deny
authenticated	 = *
condition = ${if or {{ !eqi{$authenticated_id} {$sender_address} }\
{ !eqi{$authenticated_id} {${address:$header_From:}} }\
}\
}
message	 = Your FROM must match your authenticated email user.

 

This will prevent users from changing their identity in webmail or their email client, which would be spoofing an email identity other than the logged in user.

Removing sendmail

Finally, since sendmail spoofing cannot be prevented easily, moving sendmail binary on the system would be the best way to cut down on spoofing and spamming. You can simply run the following command:

Code:
mv /usr/sbin/sendmail /usr/sbin/sendmail.bak`date +"%Y%m%d%H%M%S"`

If your sendmail is not at /usr/sbin/sendmail, you could run whereis to locate it:

Code:
whereis sendmail

Please note that any forced cPanel updates (/scripts/upcp –force) or exim updates (/scripts/eximup) would replace the missing binary. You will need to manually move the file each time those scripts are executed or use /scripts/postupcp and /scripts/posteximup files to run the command to move the file again. The script could simply have the following content:

Code:
#!/bin/sh
mv /usr/sbin/sendmail /usr/sbin/sendmail.bak`date +"%Y%m%d%H%M%S"`

After creating the scripts, ensure they has execute permissions to run:

Code:
chmod +x /scripts/postupcp
chmod +x /scripts/posteximup

Please note that you cannot make the sendmail binary file immutable with blank contents as it is still replaced during eximup regardless, so the only viable option to keep it from being replaced would be to create the previously mentioned scripts.

Cautionary Note: Once sendmail is no longer working on the machine, your users will no longer be able to use it for scripts. They must use SMTP authentication in scripts rather than functions that call the sendmail binary. Most major applications such as Joomla do have an option to use SMTP authentication instead, but you are going to have many customers who relied on scripts that used PHP mail() function calling sendmail or who called sendmail directly, and those users will be impacted by this change. Please ensure that your users are well aware this is going to happen before removing sendmail functionality. It is best to test the repercussions it will have on services on your machine before making such a change permanent.

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

*