Jailing Services

SASL and LDAP make configuring Postfix a tad more complex. Most Linux distributions, including Ubuntu, tend to lock Postfix in its own chroot environment, which is a very superficial form of virtualization. A process locked in a chroot jail views the chroot folder as the root folder of its own filesystem.

This arrangement basically has a similar effect to using a container, even if a chroot does not provide its own namespaces for process IDs or network interfaces, unlike real containers. Nevertheless, the use of chroot for Postfix offers additional security. If chroot is active, a successful attack on the mail server keeps the attacker from gaining immediate access to the host's filesystem. The attacker simply can't see the rest of the filesystem because of the chroot.

Of course, the use of chroot means that all the files to be accessed by Postfix also need to reside within the chroot environment, which in the standard configuration affects the socket that the SASL daemon uses to communicate with its clients. Fortunately, this problem has plenty of slot-in solutions. For example, SASL can be configured so that it stores its socket in the Postfix chroot directory, which is also the recommended configuration.

Speaking of configuration: You can make your life far easier by automating the process of configuring the mail server. Ansible can be put into operation quickly for individual systems; you can find plenty of ready-made Ansible roles online for Postfix on Ubuntu. If you rely on Ansible or some other automation tool, you get all the advantages of automation at virtually no cost and mitigate the risk of careless errors. This approach even gives you a contingency plan: If a system falls victim to an attack and is considered compromised, a replacement can be set up quickly with an existing automation system.

Incidentally, similar considerations apply if the same machine will also be acting as an IMAP server. Dovecot is recommended as a standard product, and it offers security options comparable to running in a chroot jail. If you want to handle the clients on the same system (e.g., with a webmail client), you can use tools such as Roundcube (Figure 1). Ideally, however, you will want to make sure the basic details of secure system administration are taken into account.

Figure 1: If you want to build an email server-in-a-box, Roundcube is a good and secure method of connecting a web-based client. © Roundcube

If you are not worried about working with containers, you now have another option for hardening Dovecot and Postfix: running mail services in containers – typically, Docker containers on Ubuntu (Figure 2). The required directories (e.g., the data directory for Dovecot, which the service uses to access mail messages) are integrated into the construct as bind mounts. Dovecot and Postfix are then completely isolated from the system, which also makes features such as high availability easier. If in doubt, you can move the container in question from one host to another, taking the IP address with it. The admittedly somewhat unloved Pacemaker cluster manager supports this ability in a relatively uncomplicated way.

Figure 2: If you run your mail services in a container (as shown here with Rspamd and Postfix), you add an additional layer of security to the system that makes it more difficult for intruders to gain access.

The ideal solution is to combine containerization and automation. Automatically rolled out containers, which Ansible or an alternative product will also configure appropriately, come close to the ideal of an indestructible infrastructure and help you avoid sleepless nights.

To supplement this article, countless how-tos can be found on the Internet that will give you a good overview of the most useful configuration directives for Postfix, including, for example, setting Postfix up to reject clients that do not say EHLO before sending email. These attempts are either poorly programmed clients or spammers. Lots of little things like this can be used to good advantage every day, but even experienced mail admins don't know them all.

Securing the Medium

Administrators who automatically roll out Postfix and Dovecot in containers while providing the solutions with working configurations have already achieved something good, but it is still too early to put your feet up. With mail servers, the focus is not only on securing the service itself, but also on securing the ability to send and receive messages. Bad habits relating to email mean that, besides needing the mail server, you also need a suitable DNS configuration, defense against spam, and secure connections to the clients and other mail servers.

Much like web servers, it is not advisable for today's mail servers to talk to any other party in plain text. Anyone who has access to the network connection between the servers could simply sniff any messages transmitted in the clear. It makes more sense to run the mail server with the Secure Sockets Layer (SSL) protocol in place, or at least to install an SSL terminator upstream of it. The best way to do this depends on your setup.

If you are already operating a containerized mail server, you can use a mesh service such as Istio for this task. It terminates SSL connections and takes care of the issue completely independently so that Postfix itself does not even need an SSL configuration. If Postfix is running as a service directly on the system, it can be made SSL-capable with just a few steps. However, you then need to disable the receiving and sending of email over unencrypted channels.

The same applies to a third conceivable scenario in which a load balancer upstream of the mail server takes care of SSL. However, be careful: If you want to use DNS-based authentication of named entities (DANE), the mail server must support STARTTLS (a protocol command that switches from plain text to a Transport Layer Security (TLS) or SSL connection), in which case you will need to provide an SSL certificate on the mail server. With STARTTLS, opening the connection is an unencrypted process, but all communication after the STARTTLS command is encrypted.

Receiving and Sending

When sending, it is important to demonstrate the authenticity of a sent email to the mail server at the other end. As described earlier, email in its original form did not provide for any measures that would have forced the sender of an email to use a specific sender address, opening the door to attacks and ultimately leading to the emergence of several semi-official techniques, some of which are now considered official Internet standards.

One of the simplest methods is the Sender Policy Framework (SPF; Figure 3), which should not be missing from any serious email setup. Put simply, SPF uses a DNS TXT record to store an entry for the sender domain the servers are allowed to use when sending email. Therefore, you need to set up your own DNS server so that only your mail server appears in the SPF entry for your domain. Conversely, your Postfix needs to check the SPF entries of the servers at the other end and reject email if it comes from an address other than the one in the SPF entry.

Figure 3: Industry leader Google is leading the way: SPF entries are a good way of preventing the misuse of sender domains.

DomainKeys Identified Mail (DKIM) does something very similar. You store the public part of a cryptographic key as another TXT entry in the domain. When email is sent, the server computes the hash of the email content and inserts the digital signature into the header fields of the email before it is sent. The receiving mail server can then check the content of the mail on the basis of the public key of the sending mail server and the digital signature. If the signature and key match, DKIM assumes that the sending server is authentic and accepts the mail; otherwise, it rejects the message. Like SPF, DKIM has become a common tool in everyday mail traffic that prevents misuse and should therefore not be missing from any mail server configuration.