Search Site:

About

Linux

Printers?

Programming

Windows?

Download

Skins

Edit - To Do - AllRecentChanges

Recent Changes Printable View Page History Edit Page

This page is part of the EmailServer article.

Foreword

This article describes the necessary steps to set up stunnel to provide alternate secured ports for postfix and dovecot (SMTP and IMAP/POP).
This technique is useful but it is not necessary since you can achieve the same result just by modifying your firewall settings to redirect traffic from any port to the secured SMTPS, IMAPS/POPS ports already provided out of the box by postfix and dovecot.

You can directly proceed to the AlternateAccess article if you don't need to use stunnel.

Secure, encrypted email channels

With the proliferation of wireless hotpots, people have been able to enjoy a new freedom in accessing the web and their emails: airport lounges, coffee shops, public spaces.
While all this freedom is wonderful, public access points (and most private ones) usually don't use any form of encryption to protect your transfers.
This is especially an issue on publicly accessible networks where absolutely anyone can eavesdrop on your communication without you being the wiser. In some countries (including the US it seems), internet communications are routinely filtered, taped or analysed for whatever purpose is deemed just, too often without any accountability.

One of the reasons that email can be the weak link in your organisation security is that most of the time authentication connections by your email client are still sent in clear text, meaning that every time you get email, you advertise your username and password.
A lot of organisations only use a single username/password for each of their users and their access needs, meaning that the same pair is not only used for authorizing access to email accounts, but also to login into your PC, domain or Intranet...

Stunnel to the rescue!

There are many ways to secure your email connections through SSL: most servers have their own configuration details allowing them to work through an encrypted channel.

Here though, will will use Stunnel to provide secured channels to postfix@2 and dovecot@@ rather than configuring each of them individually.

Stunnel is also easy to use and can allow you to create ad-hoc secure tunnels for any arbitrary network service as well.

Installing Stunnel

If Stunnel isn't on your machine yet (whereis stunnel), just grab it from your rpm repository (yum install stunnel) or get the source code from stunnel.org.

To install from yum as usual:

# yum -t install stunnel

To install the source code:

# cd /usr/local/src
# wget http://www.stunnel.org/download/stunnel/src/stunnel-X.XX.tar.gz
# tar xzvf stunnel-X.XX.tar.gz
# cd stunnel-X.XX
# ./configure
# make
# make install

Note that if you are installing on a RedHat machine, you may need to modify the files tools/Makefile.am and tools/Makefile.in to replace any occurrence of nogroup with nobody instead.

Note as well that the default installation directory is /usr/local/bin. If you don't want this, use the --prefix option of configure (call it with --help to get more details about the available options).

Creating the private key and certificate

Certificate of Authority

Creating a Self-Signed Certificate is only half of the story: since they are not issued by a recognised authority your mail clients will popup an information message to the user. The only way to solve this is to register your server with a recognized authority such as Verisign.
This isn't necessary, but larger organisations may want to look into the details of providing this extra-security to their users as it ensures that your server is really who it claims to be.

To be able to encrypt the communication, Stunnel needs to have access to a secure and unique private key and a certificate that it can issue to the clients connecting to it.
the certificate will contain information about your organisation and a public key that will be used by to encrypt data that can only be decrypted by the server running stunnel.

This step is important: don't use any default key that comes with your system: the communication channels would still be encrypted, but since these keys are publicly available, your communications could be decrypted without too much hassle.

To create the necessary keys just do the following:

# cd /etc/stunnel
# openssl req -newkey rsa:1024 -keyout privkey.pem -nodes  \
         -x509 -days 365 -out cert.pem

You will be asked a number of questions regarding your organisation. These will be included in the certificate issued by Stunnel when contacted by clients.
Also make sure you use the FQDN (Fully Qualitified Domain Name) of your email server when asked about your server name (for instance, mail.example.com).

Note that the certificate will only be available for the number of days specified when creating it. You can make your certificate valid for as little or as long as you wish.

Now, Stunnel requires that both certificate be in a single file with extra blank lines after each certificate.
Like most encryption-related configurations, it also requires that the certificate have limited access.
After creating the proper key, we don;t need the original ones any longer.

# cat privkey.pem > stunnel.pem
# echo "" >> stunnel.pem
# cat cert.pem >> stunnel.pem
# echo "" >> stunnel.pem
# chmod 600 *
# rm privkey.pem cert.pem

That's it, Stunnel is ready to be configured:

Create the /etc/stunnel/stunnel.conf with the following entries:

cert = /etc/stunnel/stunnel.pem

[imaps]
accept  = 993
connect =  143

[pops]
accept  = 995
connect =  110

[smtps]
accept  = 465
connect = 25

What this does is simply tell stunnel to listen to ports 993, 995 and 465 and spit out the decrypted stream of data to ports 143, 110 and 25.
The cert line should not be necessary unless you compiled stunnel from source and it is expecting a different path (check what it could be by running stunnel version).

Now we can try to launch stunnel manually to check that it works:

# stunnel

That's all that should be needed. If you are getting error messages, then try to add the path to your stunnel.conf file. If there are any other errors, we won't see them and stunnel won't tell us whether eveything is fine or not.
To make sure everything is OK, have a look at the /var/log/secure log file, it should end with the following lines:

... stunnel 4.08 on i386-redhat-linux-gnu PTHREAD+POLL+IPv4+LIBWRAP with OpenSSL 0.9.7f
... 500 clients allowed

If you get an error saying that the binding address is already in use check that your protocols entry in the /etc/dovecot.conf file doesn't contain pop3s or imaps.

To Allow Stunnel to become a normal service like any other, we're going to install an init script for it.

A script is provided in the source code tree under tools/stunnel.init but I recommend you get my copy instead as I have modified it to be manageable with the chkconfig and service utilities.

Install the service and schedule it to run:

# cp stunnel.init /etc/init.d/stunnel
# chmod 755 /etc/init.d/stunnel
# chown root.root /etc/init.d/stunnel
# chkconfig --add stunnel

That's should be all. You can check that stunnel will start and stop by using service stunnel start or service stunnel stop.

Resources

< Firewall | EmailServer | AlternateAccess >

Leave your comments below
Enter your comment (no links allowed): Author:

Edit Page - Page History - Printable View - Recent Changes - WikiHelp - Search - RSS -
Page last modified on Friday 23 January 2009, at 07:49 GMT+8 - Viewed 2602 times