Command Center

The preferred email protocol for this configuration is IMAPS as all emails are stored on the main server and then replicated through to your MUA client when it connects. Because the mail files on the server and client are synchronised, the webmail application will have all the emails contained on your local workstation and vice versa, including sent emails.

Basic Configuration

Sendmail

Do not edit sendmail's "cf" file, use the "mc" macro file to make the changes. This backup is only a precautionary measure in case everything goes bad.

If alias file (/etc/aliases) is adjusted, it needs to be updated with the "newaliases" command before settings are implemented.

You should consult the README file for further details on available settings ("/usr/share/sendmail-cf/README").

Mail Aliases - Who gets Who's Email

Dovecot IMAP Server

If you plan on setting up SquirrelMail for your webmail requirements, you will need to have the IMAP protocol enabled.

User Email Accounts

When a standard user account is created on the server, that user is automatically granted access to login to the system and is also able to send and receive emails. The user now really only needs to configure their MUA with the details of the servers address and their account details, and email should be fully accessible.

Creating a standard user account with a false shell stops that account from being able to log into the system (a Linux login), but still allows them to use the system for the purpose of sending and receiving emails. Creating a user account using the following example, is the easiest method for creating email only accounts for friends and family where they do not require login access to the server.

[bash]# useradd -c "Alice Jones" -s /sbin/nologin alice

Email only accounts forbid a user from logging in and accessing their home directories. These accounts may not be suitable if users expect access to their "public_html" directories if they are present.

You may also consider placing all of the email only accounts into an appropriately named group for easy management.

Starting the Services

Starting the newly configured services are relatively straight forward, however if any changes have been made to the sendmail macro file or access lists, then the sendmail.cf file will need to be recompiled before any of the changes will be accepted. These days many of the initscripts handle this task automatically, however its good to do it manually just to be certain.

[bash]# make -C /etc/mail

The services should now be set at the appropriate runlevels and then checked to ensure they are correct.

[bash]# chkconfig --level 2345 sendmail on [bash]# chkconfig --level 2345 dovecot on [bash]# chkconfig --list sendmail [bash]# chkconfig --list dovecot

The services can now be started. The system logs should also be checked to ensure there are no errors.

[bash]# /etc/init.d/sendmail restart [bash]# /etc/init.d/dovecot restart

[bash]# grep sendmail /var/log/maillog [bash]# grep dovecot /var/log/maillog

You've got email !

Preventing Abuse

Open mail relays

The worst exploitation of an email system is if its able to relay emails for everyone, this allows spammers and other nasty organisations to use your unprotected system as a platform for their malicious activities. Although we have defined who can use the system in the above configurations (access database), we can take extra precautions to minimise the effects of any possible damage.

The following example is a basic open relay test that you can perform on your sendmail server as an example of how easy it is for a spammer to send emails through an insecured MTA. Firstly you need to telnet into your server on port 25 (SMTP) and then cut and paste the following text into the telnet session; remembering to change the "RCPT To:" address to your own email.

[bash]# telnet localhost 25

(CUT AND PASTE BELOW TEXT) (Change "RCPT To:" email address) HELO example.com MAIL From: TheBoss@example.com RCPT To: sysadmin@example.com                     <-- Change this to your own email to see results. DATA Subject: Think we're insecure... I have a feeling our mail server is being abused... . QUIT

Now if you check your email you will notice an email from "TheBoss" and you'll see how easy it is to spoof an email. If this worked, it means that you have probably enabled your "/etc/mail/access" database with the correct RELAY permissions for it to occur. However, we only want to allow the correct clients to be able to relay through the MTA.

The following telnet test is an another open relay test that will automatically test your system from a remote Internet based relay attempt. Approximately 19 relay tests are conducted with results displayed as they occur, this is a good test of your systems configuration; it your server is open to relay, the spammers will find you soon.

[bash]# telnet relay-test.mail-abuse.org

If any of the open relay tests return serious warnings, you should seriously check your systems configuration - guaranteed your system will be exploited.

Email limits

The default file size for sendmail is unlimited, so if someone tries to send a tar archive over 2 GB throught the system, it will most likely crash the MTA while trying. A maximum file size should be set so sendmail knows when to reject a file that is too large.

[bash]# vi /etc/mail/sendmail.mc

define(`confMAX_MESSAGE_SIZE',`52428800')dnl

If you are using a PHP based webmail application like SquirrelMail, you can adjust the max file size for PHP to match the same amount; this allows PHP applications to match your mail server size limits.

## ONLY NEEDED TO SUPPORT PHP WEBMAIL ## [bash]# vi /etc/php.ini post_max_size = 50M upload_max_filesize = 50M memory_limit = 64M

The following settings limit the rate of connections, the amount of running 'children', and the maximum number of recipients for each email. By specifying these types of directives it limits the rate of any possible exploitation or Denial of Service attacks. These would be suitable for a small office or home network, but may need to be increased for larger demands.

define(`confMAX_DAEMON_CHILDREN',`5')dnl define(`confCONNECTION_RATE_THROTTLE',`3')dnl define(`confMAX_RCPTS_PER_MESSAGE',`50')dnl

This section provides a few basic settings as an introduction to possible abuse situations and should provide you with some security considerations for your system. You should always check your system logs for any signs of abuse, and do some form of test attack on your own system (from the outside of course).

Full SSL/TLS Encryption

One of the easiest ways for any system to be exploited is for a username and password to be intercepted whilst traveling through the Internet, the basic action of logging into your server from the external (Internet) side opens your user credentials to such a risk. Luckly both Sendmail and Dovecot can both be covered by TLS and SSL encryption systems to ensure your credentials and correspondence stay safe.

To configure sendmail with TLS / SSL encryption, edit the main configuration file and make the following changes. The first setting disables plain text authentication, the second defines the trusted authentication mechanisums (to allow relaying), the third defines the SSL certificate files and the fourth enables the TLS link encryption and opens port 465 for secure emails (SMTPS).

[bash]# vi /etc/mail/sendmail.mc

define(`confAUTH_OPTIONS', `A p')dnl

TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

define(`confCACERT_PATH',`/etc/pki/tls/certs')dnl define(`confCACERT',`/etc/pki/tls/certs/ca-bundle.crt')dnl define(`confSERVER_CERT',`/etc/pki/tls/certs/sendmail.pem')dnl define(`confSERVER_KEY',`/etc/pki/tls/certs/sendmail.pem')dnl

DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl

The bottom option causes sendmail to additionally listen for secure connections on port 465 through enforced SSL. Basic SMTP is still configured through port 25 for remote MTA connections and TLS.

In our initial configuration, we allowed sendmail to accept SMTP email from all hosts (the default is only from 127.0.0.1, itself). By changing this setting back to it's default, then only the local server can send unsecured emails, this is ideal if you are going to configure webmail to run from the local Apache web server.

Change This: DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl

Back To: DAEMON_OPTIONS(`Port=smtp, Addr=127.0.0.1, Name=MTA')dnl

Now that sendmail had been configured for encrypted connections and authentication, you will need to create your SSL certificates before you can activate your new configuration; this can be done using the automated scripts located in the "/etc/pki/tls/certs" directory.

[bash]# cd /etc/pki/tls/certs [bash]# make sendmail.pem

Country Name (2 letter code) [GB]:AU State or Province Name (full name) [Berkshire]:QLD Locality Name (eg, city) [Newbury]:Brisbane Organization Name (eg, company) [My Company Ltd]:Miles Brennan Organizational Unit Name (eg, section) []:Home Linux Server Common Name (eg, your name or your server's hostname) []:galaxy.example.com Email Address []:sysadmin@example.com

You should now be able to send secure emails to your MTA (Sendmail) for delivery to remote addresses.

The next step is to configure Dovecot so you may be able to successfully retrieve emails from your mail server using SSL encryption; sending is only half way there, the receive path also needs to be configured. Open your Dovecot configuration and make the following adjustments. A point to note is that we are configuring the Dovecot server to use the exact same SSL certificates that the Sendmail server is using.

[bash]# vi /etc/dovecot.conf

ssl_disable = no ssl_verify_client_cert = no ssl_parameters_regenerate = 168 ssl_cipher_list = ALL:!LOW ssl_cert_file = /etc/pki/tls/certs/sendmail.pem     <-- NOTE: Can use same certificate as Sendmail ssl_key_file = /etc/pki/tls/certs/sendmail.pem      <-- NOTE: Can use same certificate as Sendmail disable_plaintext_auth = yes

We can also block Dovecot from allowing any insecure client connections by forcing the server to only accept secure IMAPS and POP3S connections.

Change This: protocols = imap pop3

To This: protocols = imaps pop3s

Now that the services have both been configured, the services will need to be restarted.

[bash]# /etc/init.d/sendmail restart [bash]# /etc/init.d/dovecot restart

If you have users on the external side of your firewall (i.e. on the Internet), you can allow both SMPTS (port 465) and IMAPS (port 993) connections to pass through your firewall with the following adjustments to your firewall script. Remember that port 25 (SMTP) is still required and will use TLS as required.

[bash]# vi /root/firewall.sh

# New INBOUND Connection: SMTP and SMTPS (over SSL) iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 25  -j ACCEPT  <-- for TLS encryption (and basic SMTP) iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 465 -j ACCEPT  <-- for SSL encryption # New INBOUND Connection: IMAPS Email Clients (Secure Link - In and Out) iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 993 -j ACCEPT  <-- for SSL encryption

[bash]# /root/firewall.sh

By default the Dovecot server will listen on all interfaces when we declare a protocol to be configured. However we can add the following options to the protocol declaration to define a more detailed configuration.

The following Dovecot configuration causes both the secure IMAPS and POP3S protocols on be active on all network interfaces, but also allow Dovecot to operate the insecure IMAP protocol only from the localhost server, this again is an ideal configuration if you intend to run SquirrelMail on your server and it is an IMAP based application.

[bash]# vi /etc/dovecot.conf

protocols = imap imaps pop3s protocol imap { listen = 127.0.0.1 ssl_listen = * ssl_disable = no }

The above Dovecot settings allow for the IMAP based SquirrelMail application to work on the local server without requiring TLS/SSL encryption. A remote user will still interface the HTTPS web interface through SSL, ensuring secure access through a web browser.

Clam Antivirus

There is really no such thing as a virus in the Linux world and what you would call a virus is really nothing more than an exploit or maliciously crafted piece of code. Some not so better operating systems however are quite susceptible to virus attacks and the number one means of virus infection is currently via the email system. Although your Linux MTA itself is quite safe from any possible virus threats, we have a duty of care to at least protect our internal workstations that may face a somewhat different fate.

Clam AntiVirus is an opensource antivirus scanning toolkit for UNIX systems. Effectively it runs as its own independent service with its own suite of applications, these need to be interfaced by other applications in order to use the scanning facilities. Sendmail interfaces into clamav with whats called a milter (Mail Filter), and the results are returned to sendmail for further processing.

Clamav-Milter

Firstly we need to install the clamav suite of applications, this command will install the clamav server and the milter required to work with Sendmail.

[bash]# yum install clamav*

The clam daemon configuration file should be backed up before any adjustments are made.

[bash]# cp /etc/clamd.d/milter.conf /etc/clamd.d/milter.conf.original [bash]# vi /etc/clamd.d/milter.conf

The following is an example of a typical clamd configuration file. The "/etc/clam.d/clamd.conf" file is well documented with configuration options and further detailed information can be obtained from reading the supporting man page. Type "man clamd.conf" at the command prompt.

The "Example" option must be commented out before the daemon will start.

#Example                              <-- This must be commented out before the daemon will function LogFile /var/log/clamd.milter LogFileMaxSize 5M LogTime DatabaseDirectory /var/lib/clamav LocalSocket /var/run/clamd.milter/clamd.sock FixStaleSocket #TCPAddr 127.0.0.1 #TCPSocket 3310 User clamilt ScanMail ScanHTML DetectBrokenExecutables ArchiveBlockEncrypted

On one side we have a running MTA (Sendmail) and the other side we have a fully functional antivirus system, clamav-milter is the glue that binds it all together. As an email is passed onto the MTA, the milter redirects it to the antivirus server and awaits the results.

The following parameters detail how the milter will act and respond between the other two systems; should it just drop all infected email, should it notify the recipient or the sender, should it inform the administrator; there are numerous available options. You should consult the man page to configure the settings that will best suit your needs. Type "man clamav-milter" at the command prompt for more details.

[bash]# cp /etc/sysconfig/clamav-milter /etc/sysconfig/clamav-milter.original [bash]# vi /etc/sysconfig/clamav-milter

CLAMAV_FLAGS="--local \               --bounce \               --advisory \               --force-scan \               --dont-wait \               --dont-log-clean \               --max-children=2 \               --server=localhost \               --postmaster=sysadmin@example.com \               --config-file=/etc/clamd.d/milter.conf \               --pidfile=/var/run/clamav-milter/milter.pid \               --signature-file=/etc/mail/clamav-email-signature \               local:/var/run/clamav-milter/clamav.sock " CLAMAV_USER='clamilt'

In the above sample configuration we are placing a footer (signature-file) on all the emails that successfully pass thru the system, as an assurance to the end recipients that the email is virus free. The following is an example signature file, it isn't required but is an option should your email policy require it.

[bash]# vi /etc/mail/clamav-email-signature

_________________________________ This email has been ClamScanned !           www.clamav.net

The service is now ready to run after we set the correct runlevels. The clamav-milter logs directly to "/var/log/maillog" when it processes an email, which can be checked after all the configurations are complete.

[bash]# chkconfig --level 2345 clamav-milter on [bash]# chkconfig --list clamav-milter

[bash]# /etc/init.d/clamav-milter restart

Now that the milter is running, we need to tell sendmail to use it. Place the following line into the sendmail.mc file, then restart the Sendmail service.

[bash]# vi /etc/mail/sendmail.mc

INPUT_MAIL_FILTER(`clamav-milter', `S=local:/var/run/clamav-milter/clamav.sock, F=T,T=S:4m;R:4m;E:10m')

[bash]# make -C /etc/mail [bash]# /etc/init.d/sendmail restart

Thats it !! You are all configured now for antivirus scanning.

Testing the Clamav Scanner

The easiest way to check if the scanner is functioning, is to check the mail logs. The details of each email that gets sent by the milter to clamd is placed in the log, the example below shows how the milter added the extra header details to the incoming email.

[bash]# grep Milter /var/log/maillog

sendmail: Milter add: header: X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on galaxy.example.com sendmail: Milter add: header: X-Virus-Status: Clean

The email can be checked at the MUA to confirm the presence of the extra milter headers on all of the incoming emails. This is confirmation that the system is configured and functioning as expected.

X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on galaxy.example.com X-Virus-Status: Clean

The European Institute for Computer Antivirus Research (EICAR) have created an antivirus test signature that can be used to test many antivirus programs. Your new Sendmail configuration can be tested by sending the EICAR test signature through as an email and check to see if Clamav identified and labelled the email as an infected message.

Issue the following command at the command line interface, ensuring that you change the email address to your own (or one you can access). When the email arrives at the email address you inserted, you can check the headers within the email and see if Clamav has inserted the following flags.

[bash]# echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' | mail sysadmin@example.com

To: sysadmin@example.com X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on galaxy.example.com X-Virus-Status: Infected with Eicar-Test-Signature Subject: [Virus] Eicar-Test-Signature

More information about the EICAR test antivirus signature can be seen at this site: http://www.eicar.org/anti_virus_test_file.htm

Freshclam updates

The Clam Antivirus system is only as effective as its latest copy of the virus definitions, these can be updated using the freshclam application. Make the following adjustments to your freshclam settings, ensuring you ADD a "#" (comment) to the "FRESHCLAM_DELAY" directive, this enables the update service.

[bash]# vi /etc/sysconfig/freshclam

FRESHCLAM_MOD=180                <-- Update interval in minutes #FRESHCLAM_DELAY=disabled-warn   <-- Add "#" to activate (enable) clamav updates

The main antivirus functions are now running and freshclam can be configured to keep the system up to date with the latest virus patterns. As normal the configuration file should be backed up.

[bash]# cp /etc/freshclam.conf /etc/freshclam.conf.original [bash]# vi /etc/freshclam.conf

This is an example of the freshclam configuration file. This file too is well documented and the supporting man page should be consulted for any further queries. Type "man freshclam.conf" at the command prompt.

If your system is behind a firewall or you prefer to use a proxy server, then ensure that you complete and enable the appropriate HTTPProxy options for your system.

#Example DatabaseOwner clamav DatabaseDirectory /var/lib/clamav Checks 24 MaxAttempts 5 UpdateLogFile /var/log/freshclam.log DNSDatabaseInfo current.cvd.clamav.net DatabaseMirror db.??.clamav.net               ###  <-- See Note. DatabaseMirror database.clamav.net #HTTPProxyServer galaxy.example.com #HTTPProxyPort 3128 #HTTPProxyUsername username #HTTPProxyPassword password

Replace "??" (above) with the two letter country code for your region, or remove line from configuration file if you are unsure.

Freshclam will automatically update itself at intervals define with the earlier "FRESHCLAM_MOD" declaration. However, if you require to update your antivirus manually to test your configuration, you can execute the command at the xterm prompt.

[bash]# freshclam

ClamAV update process started at Sun May 21 12:01:57 2006 main.cvd is up to date (version: 38, sigs: 51206, f-level: 7, builder: tkojm) Downloading daily.cvd [*] daily.cvd updated (version: 1472, sigs: 4793, f-level: 8, builder: arnaud) Database updated (55999 signatures) from db.au.clamav.net (IP: 61.8.0.16)

Freshclam keeps a log of all update details.

[bash]# tail /var/log/freshclam.log

SpamAssassin

One of the biggest wastes of bandwidth throughout the Internet today is from unwanted/unsolicitated bulk email, in other words spam; we hate it. Unfortunately for us it isn't going to go away for a while, fortunately we can at least filter some of it out of our Inbox by using SpamAssassin which comes standard now with many Linux distributions. SpamAssassin will at the very least allow you to take some control back over your email account.

To install SpamAssassin and the required milter for Sendmail, type the following command at the prompt.

[bash]# yum install spamass-milter spamassassin

SpamAssassin has many plugins written and available for use, they can be enabled in the "/etc/mail/spamassassin/v310.pre" plugin file. The plugins file is the first configuration to be loaded by SpamAssassin.

[bash]# cp /etc/mail/spamassassin/v310.pre /etc/mail/spamassassin/v310.pre.original [bash]# vi /etc/mail/spamassassin/v310.pre

loadplugin Mail::SpamAssassin::Plugin::DCC loadplugin Mail::SpamAssassin::Plugin::Pyzor loadplugin Mail::SpamAssassin::Plugin::Razor2 loadplugin Mail::SpamAssassin::Plugin::SpamCop loadplugin Mail::SpamAssassin::Plugin::AWL loadplugin Mail::SpamAssassin::Plugin::AutoLearnThreshold loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject loadplugin Mail::SpamAssassin::Plugin::MIMEHeader loadplugin Mail::SpamAssassin::Plugin::ReplaceTags

The "/etc/mail/spamassassin/local.cf" file is the main global configuration file for the whole server and can be configured like so.

[bash]# cp /etc/mail/spamassassin/local.cf /etc/mail/spamassassin/local.cf.original [bash]# vi /etc/mail/spamassassin/local.cf

required_score          5.0 rewrite_header subject  [SPAM] report_safe             1 use_bayes               1 use_bayes_rules         1 bayes_auto_learn        1 skip_rbl_checks         0 use_razor2              1 use_dcc                 1 use_pyzor               1 trusted_networks        192.168.1/24 127/8 internal_networks       192.168.1/24 127/8

If you need assistance in determining which configuration options are the best for your system, you can use the online "SpamAssassin Configuration Generator" located at: "http://www.yrex.com/spam/spamconfig.php". your customised online configuration can then be downloaded into your /etc/mail/spamassassin/local.cf file.

To define daemon runtime options, edit the system configuration file for SpamAssassin.

[bash]# cp /etc/sysconfig/spamassassin /etc/sysconfig/spamassassin.original [bash]# vi /etc/sysconfig/spamassassin

SPAMDOPTIONS="-d -c -l -m5 -H"

Users can also fine tune their own options for SpamAssassin by editing their own user configuration files located in their home drives.

[/home/miles]$ vi ~/.spamassassin/user_prefs             <-- executed as basic user

The SpamAssassin mail filter (milter) can then be configured with runtime options.

[bash]# cp /etc/sysconfig/spamass-milter /etc/sysconfig/spamass-milter.original [bash]# vi /etc/sysconfig/spamass-milter

SOCKET=/var/run/spamass-milter/spamass-milter.sock EXTRA_FLAGS="-r 15"

The daemons need to be configured to start at the appropriate runlevels using the following commands, this should also be checked to ensure the daemons will initialise at expected if needed at next reboot.

[bash]# chkconfig --level 2345 spamassassin on [bash]# chkconfig --level 2345 spamass-milter on [bash]# chkconfig --list spamassassin [bash]# chkconfig --list spamass-milter

Once the services has been configured, the daemons can both be restarted.

[bash]# /etc/init.d/spamassassin restart [bash]# /etc/init.d/spamass-milter restart

The SpamAssassin configurations have now been completed, however the mail server has not yet been configured to use the spam filtering daemon yet. Before we do the final configuration, it is important to firstly test that SpamAssassin is functioning as expected and the email that passes through the daemon is handled correctly. If we don't do these tests then some of your email may just disappear because of a poorly configured service.

The first test passes a test email to the spam daemon and returns the results to the screen. This test email is considered by SpamAssassin to be clean and should return a clean result.

[bash]# spamassassin -t < /usr/share/doc/spamassassin-3*/sample-nonspam.txt | grep X-Spam

X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on galaxy.example.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable

The second test passes an email that is considered by SpamAssassin to contain spam signatures, as such the test should return a positive result to the test. You should note the "X-Spam-Flag: YES" flag that SpamAssassin inserts into the email's headers, this will allow users an easily way to identify and automatically sort spam affected emails into junk email folders as they arrive in their Inboxes.

[bash]# spamassassin -t < /usr/share/doc/spamassassin-3*/sample-spam.txt | grep X-Spam

X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on galaxy.example.com X-Spam-Level: ************************************************** X-Spam-Status: Yes, score=1000.0 required=5.0 tests=GTUBE,NO_RECEIVED,

Once you are happy that the outcomes of both your spam and non-spam tests are successful, Sendmail can be configured to pass emails to the SpamAssassin daemon by use of the mail filter (milter).

[bash]# vi /etc/mail/sendmail.mc

INPUT_MAIL_FILTER(`spamassassin', `S=unix:/var/run/spamass-milter/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher}, {cipher_bits}, {cert_subject}, {cert_issuer}')dnl

Now that the SpamAssassin milter settings have been inserted into the Sendmail configuration, the Sendmail server can be restarted; this will complete your installation.

[bash]# make -C /etc/mail [bash]# /etc/init.d/sendmail restart

For further information on SpamAssassin configuration, you can view the following man pages: "Mail::SpamAssassin::Conf" and "Mail::SpamAssassin".

REFERENCE
http://www.brennan.id.au/12-Sendmail_Server.html