Sendmail Versions on Debian
7.4.8 Sendmail and SMTP AUTH
The security controls I’ve covered so far are all important: they’re things that should be enabled and configured on any publicly accessible Sendmail server. But Sendmail has two relatively new features that take Sendmail security even further: authentication and encryption. Let’s start with authentication. SMTP AUTH, described in RFC 2554 (ftp://ftp.isi.edu/in-notes/rfc2554.txt), is a badly needed extension to the SMTP protocol: it describes a flexible authentication mechanism that can be used to authenticate relaying. SMTP AUTH allows a password shared by two hosts (or stored by one host for its local users) to be used to validate email senders.
Naturally, it’s both unfeasible and counterproductive to authenticate all SMTP transactions, i.e., those involving mail addressed to or sent by users who verifiably reside on your local system or name domain. But authentication is extremely useful in two different SMTP-relaying contexts, which I’ll call "server-server" and " client-server."
In server-server relaying, a user sends mail to Server A, Server A authenticates to Server B and relays the mail through it, and Server B delivers the mail to its remote destination (Figure 7-1). Typically, Server A is an internal mail server, and Server B is a DMZed SMTP gateway.
Figure 7-1. Server-to-Server Relaying
The second context for SMTP AUTH, one which is probably more widely used, is client-server SMTP relaying, in which remote users authenticate back to their "home" SMTP gateway to send (relay) their outgoing mail (Figure 7-2). This is a handy way to let users move between your internal network and external sites without reconfiguring their email-client software.
If you’re running an SMTP server that receives mail relayed from other domains, you probably want to use SMTP AUTH: it’s an important defense against Unsolicited Commercial Email, the perpetrators of which rely heavily on open SMTP relays.
Figure 7-2. Client-server SMTP relaying
Depending on which authentication mechanism you choose, it may make sense to encrypt your SMTP AUTH transactions via Sendmail’s TLS features. TLS stands for Transport Layer Security, which is the IETF’s standard for and successor to Netscape Communications’ versatile and ubiquitous SSL (Secure Sockets Layer) v3 protocol. As with HTTP, SMTP sessions even between unauthenticated hosts can be transparently encrypted using this protocol. Also as with HTTP, it appears that SMTP users tend to use TLS/SSL in this way rather than leveraging the powerful digital-certificate-based authentication mechanisms supported by TLS and SSL.
This isn’t too surprising: one of the ugly realities of modern IS security is that Public Key Infrastructure (PKI) technologies are complicated, unwieldy, and difficult to maintain. By combining digital certificates (used as strong but unverified encryption keys) with other, simpler authentication mechanisms such as SASL, many people feel they get "the best of both worlds."
7.4.8.1 Versions of Sendmail that support SMTP AUTH
SMTP AUTH support in Sendmail was introduced with Sendmail v.8.10. As mentioned earlier in the chapter, Red Hat 7 and SuSE 7 both ship with binary packages of Sendmail v.8.11. However, while Red Hat’s standard sendmail package has SMTP AUTH support compiled in, SuSE’s doesn’t: if you want SMTP AUTH, you need the package sendmail-tls, which can be found in SuSE 7.x’s sec2 package series. Debian 2.2’s ("Potato’s") Sendmail package is v.8.9, which predates Sendmail’s adoption of SMTP AUTH. However, the current testing distribution (a.k.a "woody") has a deb package of Sendmail 8.12.1, which does have SMTP AUTH support compiled in.
If you don’t use one of these three distributions and yours lacks an SMTP AUTH-enabled Sendmail package, you may need to download the latest Sendmail source code from http://www.sendmail.org and compile it yourself. Before you build, however, be sure to read Claus Aßmann's article "SMTP AUTH in sendmail 8.10-8.12" (http://www.sendmail.org/~ca/email/auth.html), which contains instructions on how to compile SMTP AUTH support into Sendmail — by default, Sendmail builds without it.
7.4.8.2 Obtaining Cyrus SASL
Sendmail actually can't authenticate anything directly, even if it has SMTP AUTH support compiled in. Rather, it depends on Carnegie Mellon University's Simple Authentication and Security Layer (SASL) package, which authenticates against its own database or against an OS mechanism such as PAM. SASL can of course be obtained from CMU (at ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/). However, it makes more sense to use your Linux distribution's binary package since if you install a binary package of Sendmail that supports SMTP AUTH, then the SASL package must satisfy dependencies in Sendmail. In Red Hat 7 the RPM package is called cyrus-sasl; in SuSE 7 it's also called cyrus-sasl and is part of the sec1 group; under Debian testing ("Woody") the required deb package is libsasl7. (There's no such package in Debian 2.2, but remember: the older version of Sendmail in Debian 2.2 doesn't support SMTP AUTH anyhow; you need the Debian-Woody sendmail and libsasl7 packages if you want SMTP AUTH.) 7.4.8.3 Configuring SASL for server-server authentication
If you want your Sendmail server to authenticate other servers, it's easiest to use SASL's own authentication database, /etc/sasldb. Sendmail can use this database in sophisticated challenge-response mechanisms such as CRAM-MD5 and DIGEST-MD5 in which no secret data (i.e., passwords) are exchanged over the network. It can also use /etc/sasldb in the much less secure PLAIN method in which the password is exchanged over the network — unencrypted! — but the PLAIN method isn't appropriate unless you're also using TLS, described later in this chapter.
Besides its compatibility with Sendmail's CRAM-MD5 and DIGEST-MD5 mechanisms, the other advantage of /etc/sasldb is that it provides an alternative set of authentication credentials besides your system- and user- account passwords. It makes sense to avoid using actual login credentials for automated network transactions such as server-server SMTP relaying.
Let's configure SASL for the server-server relay scenario, then. This takes only two steps. First, we create a small, one-line configuration file telling SASL how Sendmail authentication should be handled. This file, /usr/lib/sasl/Sendmail.conf, only needs to define the variable pwcheck_method. Possible methods include sasldb (authenticate using /etc/sasldb), pam (use the operating system's PAM logon mechanism), and kerberos_v4 (use the local Kerberos infrastructure, assuming there is one).
Example 7-10 shows a SASL Sendmail.conf file for a Sendmail server that authenticates relays from other servers via /etc/sasldb.
Example 7-10. /usr/lib/sasl/Sendmail.conf with sasldb authentication pwcheck_method: sasldb
The second step is to create and populate /etc/sasldb with at least one user account.Do this with the following command:
saslpasswd username
This account should not use any username or password in /etc/passwd. Since no one will have to type the password in our server-to-server transaction, there's no reason for it to be short or simple. Example 7-11 shows a sample password-creation session (with the password shown for illustrative purposes — it isn't echoed back to the screen in a real saslpasswd session).
bash-# saslpasswd maildroid Password: Ch1mp? ,03fuzz fl0ppi
Again (for verification): Ch1mp? ,03fuzz fl0ppi
Remember that password (or write it down in a safe place): you’ll use it to configure any Sendmail hosts that need to relay mail to the one on which you created the account on. (We’ll discuss how to do so shortly.) Note that if this is the first time we’ve run saslpasswd, this command will automatically create /etc/sasldb. Subsequent invocations of saslpasswd will append to the database and not overwrite it.
We can see the fruit of our saslpasswd labors by entering, without flags or arguments, the command sasldblistusers (Example 7-12).
Example 7-12. Using sasldblistusers bash-# sasldblistusers
user: maildroid realm: dmzmail.polkatistas.org mech: PLAIN user: maildroid realm: dmzmail.polkatistas.org mech: CRAM-MD5 user: maildroid realm: dmzmail.polkatistas.org mech: DIGEST-MD5 If for any reason you wish to delete an account you’ve created in /etc/sasldb, you can do so with saslpasswd’s -d flag, i.e.:
saslpasswd -d username
Once /usr/lib/Sendmail.conf and /etc/sasldb are ready, we can configure Sendmail for authentication. If you’re doing so as you read this (and it’s a server-server relay scenario), skip to Section 7.4.8.5. 7.4.8.4 Configuring SASL for client-server authentication
IIf your Sendmail server needs to authenticate individual users instead of other servers (e.g., remote users), SASL configuration is much simpler. All we need to do is create a /usr/lib/sasl/Sendmail.conf file that sets pwcheck_method to pam (Example 7-13).
Example 7-13. A /usr/lib/sasl/Sendmail.conf file for client-server authentication pwcheck_method: pam
And that’s it! Since SASL will use the existing local PAM mechanism to authenticate prospective relays, there’s no need to create /etc/sasldb.
Once /usr/lib/Sendmail.conf and /etc/sasldb are ready, we must configure Sendmail for authentication. If you’re doing so as you read this (and it’s a client-server relay scenario), skip to Section 7.4.8.6.
Your distribution’s SASL package may support other authentication methods beside those described in this chapter. Although one or more of these other methods may be a viable option for authenticating your remote users, pam is the most convenient method on most Linux systems, which is why I’m focusing on that method here.
7.4.8.5 Configuring Sendmail for server-server authentication
There are two files to edit to prepare our Sendmail server to authenticate other servers for relaying. The first, predictably, is /etc/mail/sendmail.mc, in which we must configure the variable confAUTH_MECHANISMS and the macro TRUST_AUTH_MECH. Both of these accept as their definition any combination of CRAM- MD5, DIGEST-MD5, PLAIN, LOGIN, GSSAPI, or KERBEROS_V4.