A network is only as secure as the weakest host connected to it. Therefore, it follows that a host is only as secure as the weakest service that it’s running. After all, the only way into a system from the network (barring esoteric kernel-level network stack vulnerabilities) is through the services that it offers. Because of this, a large part of network security involves ensuring that your services are configured securely. This entails configuring services to provide only the functionality that’s required of them to accomplish the tasks they need to perform. Additionally, you should give services access to only the bare minimum of system resources needed.
That’s just part of the solution, though. If a network service operates in clear-text, all of your work spent locking it down can be for nothing. In most cases, all an attacker has to do to gain access to such a service is use a packet sniffer to capture the login details of a user authenticating with the service.
This chapter shows how to deploy IMAP, POP3, and SMTP servers that are protected with encryption, in order to prevent your users from accidentally disclosing their login credentials and keep their data safe from prying eyes. You’ll also learn how to securely deploy DNS services and MySQL. In addition, you’ll learn how to deploy Apache with SSL support and how to keep your users’ CGI scripts from accessing files that they normally wouldn’t be able to access.
Keep your email safe from prying eyes while also protecting your POP and IMAP passwords.
Having your email available on an IMAP server is invaluable when you need to access it from multiple locations. Unlike POP, IMAP stores all your email and any folders you create on the server, so you can access all of your messages from whatever email client you decide to use. You can even set up a web-based email client so that you can access your messages from literally any machine with an Internet connection and a web browser. However, you’ll almost certainly need to cross untrusted networks along the way. How do you protect your email and your account password from others with undesirable intentions? You use encryption, of course!
If you already have an IMAP or POP daemon installed that does not have the ability to use SSL natively, you can use stunnel [Hack #100] to wrap the service in an SSL tunnel. If you’re starting from scratch, though, you have the luxury of choosing a daemon that has SSL support compiled directly into the binary.
One daemon that supports SSL out of the box is Dovecot (http://www.dovecot.org). Dovecot includes support for both IMAP and POP3 and has the added benefit that it was designed and written with security in mind from the very beginning. In pursuit of that goal, it makes use of best-of-breed secure coding practices as well as privilege separation and chroot()-ing. Additionally, Dovecot is very flexible and supports a number of authentication methods, as well as both
mbox and MailDir mailbox formats.
To compile and install Dovecot, download the compressed tar archive and run the following commands:
$tar xfz dovecot-1.0.beta5.tar.gz$cd dovecot-1.0.beta5$./configure && make
This will build Dovecot with facilities to support most commonly used authentication mechanisms. If you want to use LDAP or an SQL database for authentication, you can build a copy that supports those mechanisms as well. Run./configure --help to see the full range of options.
Once you’ve compiled Dovecot, become root and run make install.
Next, to create self-signed certificates, run the following command:
$openssl req -new -x509 -nodes -out /etc/ssl/certs/dovecot.pem -keyout \/etc/ssl/private/dovecot.pem -days 3650
Alternatively, you can sign the certificates with your own Certificate Authority (CA) [Hack #69].
All that’s left to do now is to create a dovecot.conf file. To do this, find the dovecot-example.conf file, which should be located in /usr/local/etc (or wherever you told configure to install it), and copy it to dovecot.conf. Creating your own custom configuration is a fairly easy process, because the example configuration is replete with comments and displays the default values for each configuration variable.
Of particular interest is the protocols variable. By default this variable is set to support unencrypted IMAP and IMAP+SSL:
protocols = imap imaps
However, if you want to support POP3 or POP3+SSL, you can add pop3 and/or pop3s to the list of values. If you want to disable unencrypted IMAP, remove the imap value.
If you placed your SSL certificate and key in a location other than the one mentioned in the previous example, you’ll need to tell Dovecot where to find them. To do this, modify the ssl_cert_file and ssl_key_file variables. For example, to use /usr/local/ssl/certs/myhostname.crt
and /usr/local/ssl/private/myhostname.key, make the following changes:
ssl_cert_file = /usr/local/ssl/certs/myhostname.crt ssl_key_file = /usr/local/ssl/private/myhostname.key
Now that you’ve done that, you’ll need to create a user account called dovecot for the imap-login process to run under. This allows the imap-login process, which is responsible for handling client connections before they have been authenticated, to operate with the least amount of privileges possible.
One other thing to be aware of is that, if you are using mbox mailboxes, you’ll need to set the mail_extra_groups variable to the group owner of your mail spool directory. For instance, if the group owner of /var/mail is mail, use the following:
mail_extra_groups = mail
Setting this enables Dovecot to create locks when it is accessing a user’s mail spool file.
Now that you’ve finished configuring Dovecot, you can launch the daemon by running /usr/local/sbin/dovecot. You should then see log entries like these:
Apr 10 19:27:29 freebsd5-vm1 dovecot: Dovecot v1.0.beta5 starting up Apr 10 19:27:29 freebsd5-vm1 dovecot: Generating Diffie-Hellman parameters for the first time. This may take a while.. Apr 10 19:27:58 freebsd5-vm1 dovecot: ssl-build-param: SSL parameters regeneration completed
That’s the final task for the server end of things. All you need to do now is configure your email clients to connect to the secure version of the service that they were using. Usually, there will be a Use Encryption, Use SSL, or some other similarly named checkbox in the incoming mail settings for your client. Just check the box and reconnect, and you should be using SSL. Be sure your client trusts your CA certificate, though, or you will be nagged with annoying (but important!) trust warnings.