Securing Dovecot IMAP, VSFTPD with TLS
3:49 PM, Wed, Dec 12 2007
It's been said a million times: Don't send unencrypted passwords over the net. It's true. Today, people are more likely than ever to be using wireless connections, or shared connections in hotels, or other places where snooping on packets is easy. And there are easy-to-use password grabber software, so grabbing passwords from a WiFi connection is easy enough for non-experts. Therefore, any interaction with a server that involves a password and valuable data should be encrypted.
In a previous article, we covered secure relaying with Postfix with TLS in depth. That handles relaying of mail ("outgoing" mail in mail client parlance). Configuration was complicated, because the system involved not just Postfix, but also the Cyrus SASL server, and extracting keys from a Java keystore. This time, we'll secure "incoming" mail, delivered by IMAP, and also FTP connections. With that, we'll have coverage of HTTP, SMTP, IMAP, and FTP, plus SSH. That covers all the ways Chiral Software's corporate users interact with the server.
Securing VSFTPD: VSFTPD stands for "Very Secure FTP Server". The old FTP server software, such as WU-FTPD, had a history of security problems. VSFTPD was created to be a secure replacement. Among its many features, VSFTPD supports TLS encryption, which is what we're going to configure.
We're using vsftpd 2.0.4. The current version is 2.0.5, which has only minor differences. Our version came with the SuSE 10.1 distribution, and is compiled with TLS support. We can confirm this:
ldd /usr/sbin/vsftpd | grep -i ssl libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7e41000)
In our Postfix configuration, we created a file which includes Chiral's secret key, Chiral's certificate signed by GoDaddy, and finally GoDaddy's intermediate certificate signed by Vericert. TLS presents the two certificates (Chiral's and GoDaddy's) to clients upon connection. Postfix wants all three of these items in one PEM file. Fortunately for us, VSFTPD wants exactly the same file, so we can point it to the file Postfix is using, by adding these lines to
# If this is set to NO all the other SSL configuration options # are turned off ssl_enable=YES # Allow anonymous connections to be secure also. allow_anon_ssl=YES # Anonymous data and logins should also be protected by TLS force_anon_data_ssl=YES force_anon_logins_ssl=YES # If activated, all non-anonymous logins are forced to # use a secure SSL connection in order to send and receive data on # data connections. Our data are what we are protecting, so YES force_local_data_ssl=YES # If activated, all non-anonymous logins are forced to # use a secure SSL connection in order to send the password. # That's what we want force_local_logins_ssl=YES # do allow TLS ssl_tlsv1=YES # do not allow older, flawed SSL protocols ssl_sslv2=NO ssl_sslv3=NO # Where the certificate is stored, # including private key, signed cert, and intermediate cert rsa_cert_file=/etc/postfix/example.pem
Now all FTP connection (including anonymous connections) and all data transfers are securely encrypted. Verify:
openssl s_client -starttls ftp -connect example.com:ftp
Now configure the client. We'll use FileZilla, a free, open-source client which is available for Windows, Linux and other operating systems. Problems show up right away. It tries to connect anonymously, before initiating encryption, but that is blocked. The command line FTP utility runs into the same problem.
The problem is that these clients try to use LOGIN as their first command. The FTP protocol is loose enough that clients can do it many different ways. We need to define exactly what we want the client to do.
FileZilla has a feature called Site Manager. Go to File, and then Site Manager.
Click on New Site.
Define a name for the site, and enter the hostname and port. Port will be 21, unless you have put the FTP server on another port. Important: set the Servertype to FTPES - FTP over explicit TLS / SSL. Set the Logontype to Normal. Enter your username and password.
Click "ok" to save the site settings, or click Connect to connect right away. Connections should work at this point.
This setup required configuring security parameters in advance. Opening a connection without knowing the settings does not work. If you are running an FTP site that also serves anonymous users, this configuration is too tight. You'll want to allow unencrypted anon access. For our site, FTP is used only for corporate use, so we have no anonymous access.
Next up: Securing Dovecot. This one is easy. Edit
/etc/dovecot/dovecot.conf, and set these parameters:
ssl_disable = no # Where the public certificates are. # public certs contains a) our signed public cert and # b) the GoDaddy intermediate cert ssl_cert_file = /etc/certs/my-public-cert.pem # Private key. See previous article about # extracting that from the Java keystore ssl_key_file = /etc/certs/my-private-key.pem # If the key is encrypted, use a key password: #ssl_key_password = # Note that Dovecot reads key files before dropping root, # so the key file should be root readable only # Unencrypted connections should be rejected disable_plaintext_auth = yes
That's it. Restart it:
# /etc/rc.d/dovecot restart
and you have mandatory secure connections.
One extra feature of Dovecot is it allows the system administrator to specify a certificate which must be present on the client, so the client must authenticate itself to the server, just as the server uses its certificate to authenticate itself to the client. Authenticating both ways is called mutual authentication, and it adds a valuable extra layer of security. Chiral Software plans to require not just encrypted communication, but mutually authenticated encrypted communication for all secure services, after our April move to the new Ubuntu software.
To recap, the main protocols used for secure commercial communication are HTTPS, IMAP, SMTP, FTP, SSH, SIP (VoIP) and chat. This article covers securing FTP and IMAP. Our previous article covered SMTP relaying, secured with TLS. Fortunately, more modern protocols, such as HTTPS and SSH, are easy to secure. We won't be doing articles on them. See the instructions for securing Apache HTTPD or Tomcat with certificates; it's very easy. And SSH is the easiest of all. Encryption is inherent in the protocol. No configuration is needed. It's secure and encrypted "out of the box".
As more voice traffic moves to SIP, security becomes more important. Unfortunately most SIP traffic today is non-secure, and woefully easy to tap. We'll do a future article showing how to make a secure SIP connection between Asterisk and an Aastra VoIP phone. Until then, we've covered all the non-voice protocols.