16.2. Simple Mail Transfer Protocol (SMTP)On the Internet, electronic mail exchange between mail servers is handled with SMTP. A host's SMTP server accepts mail and examines the destination address to decide whether to deliver the mail locally or to forward it on to some other machine. If it decides to deliver the mail locally, it recodes the mail headers and delivery address into the proper form for the local delivery program, and it then hands the mail to that program. If it decides to forward the mail to another machine, it modifies the headers and contacts that machine (usually via SMTP, but sometimes via UUCP or another protocol) and forwards the mail.
SMTP is a store-and-forward system, and such systems are well suited to firewall applications, particularly those using proxy services. In Chapter 9, "Proxy Systems", Figure 9-2 shows how mail sent from an individual user's workstation is directed initially to a gateway system before leaving the user's own network. Mail entering a network goes to a gateway system on that network before being distributed to individual users on other hosts.
16.2.1. Extended SMTP (ESMTP)Extended SMTP (ESMTP) is an update to SMTP. It runs on the same port as regular SMTP, and ESMTP clients and servers are compatible with SMTP clients and servers. ESMTP is not actually a new protocol but a mechanism for supporting extensions to SMTP. Different mail servers implement different extensions; you can't tell what features a mailer has just by knowing that it supports ESMTP. In fact, since all the ESMTP extensions are optional, there are mail servers that speak ESMTP without implementing any new functions that affect mail handling.
The ESMTP mechanism presents no security advantages or problems different from the ones found with SMTP; it is the individual extensions that are important. From a security perspective, STARTTLS is the most interesting extension, and it is discussed in the next section.
You may want to have an ESMTP-capable server that supports performance and administrative extensions. In that case, you should make certain to pick a mail server for your bastion host that supports the particular extensions that you are interested in.
16.2.2. TLS/SSL, SSMTP, and STARTTLSSMTP passes all traffic over the network unencrypted. As we discussed earlier, various systems for encrypting and digitally signing message bodies work without changing the SMTP protocol itself. These techniques do not protect message headers, which include the email addresses of the sender and recipients, the time, and frequently the message subject. People have therefore suggested running SMTP over SSL or TLS (TLS and SSL are discussed further in Chapter 14, "Intermediary Protocols"), which would encrypt the entire connection, including all mail headers, and would also authenticate the mail relay machines.
Several methods have been proposed, including using a separate TCP port for a new SSMTP protocol. Although a port has been reserved for use by SSMTP, very few mail servers support it, and it is not a standard. An alternative that is being proposed as a standard is based upon an ESMTP extension called STARTTLS. When a client discovers that an ESMTP server supports the extension, it issues the STARTTLS command and negotiates a TLS session. The client and server then begin a completely new authenticated and encrypted dialog. STARTTLS is supported by some current mail servers, but not many.
As we have already discussed, single-hop encryption and authentication are not very useful for electronic mail. SMTP is no exception, and STARTTLS or SSMTP will be useful to you only in situations where you are directly accepting mail from known, trusted hosts (business partners or your own users, for instance).
16.2.3. Packet Filtering Characteristics of SMTPSMTP is a TCP-based service. SMTP receivers use port 25. SMTP senders use a randomly selected port above 1023.
Normally, you want to configure your packet filters to allow incoming and outgoing SMTP only between external hosts and the bastion host, and between the bastion host and your internal mail servers.
Do not allow external hosts to contact random internal hosts via SMTP. As we've discussed, only specially configured hosts can safely accept SMTP connections.
If you cannot filter on the ACK bit, you cannot safely allow outgoing SMTP connections directly from random internal hosts, as we demonstrate in the final example in Chapter 8, "Packet Filtering". If you can filter on the ACK bit, you can allow internal hosts to send mail to external hosts, but it isn't advisable to do so. Although it shouldn't increase your vulnerability to direct attacks from the outside, it dramatically increases your vulnerability to internal problems, including Trojan horse programs that users may be running unintentionally. Because port 25 is frequently allowed through packet filtering systems, it is one of the most popular ports to use for Trojan horses and other attempts to subvert firewalls.
Allowing outgoing SMTP from all internal hosts also increases the likelihood that you're going to send misformatted mail, because the mail (mis)configurations of all your machines will be visible to the external world, and the chances that all your internal machines do all the right things with mail headers (particularly in adding fully qualified domain names to addresses and "Message-ID:" lines) are low. Sending outgoing mail via the bastion host allows the bastion host the opportunity to clean up the headers before the mail is loosed upon the world.
Finally, if you allow all internal hosts to send mail to the outside, you are creating a configuration where the same machines handle internal and external mail delivery. The dangers of this sort of configuration are discussed later in Section 16.2.6, "Configuring SMTP to Work with a Firewall".
16.2.4. Proxying Characteristics of SMTPBecause SMTP is a store-and-forward protocol, it's inherently suited to proxying. Since any SMTP server can be a proxy, it's rare to set up separate proxying for it. Instead, most sites direct SMTP connections to a bastion host running a secure SMTP server that is the proxy.
Dedicated firewall products that provide proxying may proxy SMTP (they can't reasonably be expected to run a full SMTP server). This is straightforward to configure because SMTP uses a single connection. In this configuration, it's not unreasonable to continue to direct the proxied SMTP connections to a single secured SMTP server on a bastion host that acts as a second proxy. Proxying protects you from unwanted connections, but not from misuses of connections; you don't want to let external hosts talk to a standard unsecured SMTP server, even through a proxy.
16.2.5. Network Address Translation Characteristics of SMTPSMTP does not use embedded IP addresses, but outgoing SMTP connections will include the internal hostname as a greeting to the destination server. In addition, some naive mechanisms used to prevent mail relaying will refuse mail unless the IP address matches the host greeting and passes a double-reverse DNS lookup. (Double-reverse DNS lookups are discussed in Chapter 20, "Naming and Directory Services".) These problems can be avoided by using a small number of servers to relay all mail to the outside, setting up static translations for them, and advertising those names externally with the translated addresses.
16.2.6. Configuring SMTP to Work with a FirewallBecause you want to send all your incoming mail through your bastion host, you need to configure your mail system in a special way. Here are the important steps to follow:
If you configure your mail servers with an internal server and a bastion host, it is important to keep internal mail from going to the bastion host. The best way of doing this is to use a split DNS system (described in Chapter 20, "Naming and Directory Services"). If the MX record that directs Internet hosts to the bastion host is also visible to internal hosts, they may attempt to deliver mail there. If this is possible, it's a security problem (it passes potentially confidential data through the bastion host unintentionally). If this is not possible, it's a usability problem (mail that should be valid bounces unexpectedly).
Why should you separate internal and external mail servers? By passing the incoming mail to a single internal server for processing, the bastion host is relieved of having to keep track of internal aliases and internal mail configuration, and you don't have to update the mailer configuration on the bastion host nearly as often. If the bastion host passes the incoming mail to a single internal server or small list of internal servers, the filtering system can restrict SMTP connections from the bastion host to just that host or hosts, reducing the number of internal systems that can be attacked via SMTP from the bastion host if the bastion host itself is compromised.
Furthermore, if the same machines handle internal and external mail delivery, an attacker that can spoof DNS information may be able to cause mail that was intended for internal destinations to be delivered to an external host. Most email messages are addressed with hostnames instead of IP addresses, and the SMTP server uses DNS to determine the matching IP address. An attacker who can manipulate DNS responses can redirect mail to a server under the control of the attacker; that server can then copy the mail and return it. This will introduce delays and will usually leave a trail in the logs or message headers, but neither of these events will usually be obtrusive, and you are unlikely to notice them promptly. Therefore, you want to avoid situations where internal and external mail delivery are handled on the machine and internal names are resolved through DNS. The most common bad configuration is one where all machines send mail directly; the easiest good configuration is one in which there is an external mail server and an internal mail server, and the external mail server has the IP address of the internal mail server configured locally (for instance, via a hosts file).
16.2.7. SendmailThe mailer most commonly used on Unix systems is Sendmail. Sendmail is very powerful, but it also has a long and troubling history of major and minor security problems.
Sendmail's security problems have been widely discussed, while the problems of other mailers have received much less attention. However, the lack of public discussion about other mailers should not lead you to assume these mailers are any more secure than Sendmail. These mailers are simply not as widely used as Sendmail, and therefore, they have fewer people -- with both good intentions and bad -- who are examining them for security problems.
Sendmail is the devil that everybody knows, which is both an advantage and a disadvantage. On the one hand, problems are going to be found in Sendmail because that's where lots of people are looking for them (because lots of people use Sendmail). On the other hand, what problems are found are likely to be fixed very quickly (again, because lots of people use Sendmail). Sendmail is very actively supported on security issues.
One of the reasons Sendmail has security problems is that it's a very complex and monolithic program. It performs several different functions, and it requires the necessary permissions to perform all of those functions. Sendmail needs root privileges for a number of reasons; for example, these privileges allow Sendmail to:
On a bastion host, it should be possible to make Sendmail run setuid to something other than root. You can use an alternative SMTP server (the smap package, discussed later) for incoming SMTP connections, so that Sendmail doesn't need to listen on port 25. You shouldn't have any users receiving mail on the bastion host, so you shouldn't need the ability to operate as particular users to read protected .forward and :include: files. There probably aren't any privileged system calls on your system that are critical to Sendmail's operation (though you may lose some functionality and/or need to recompile Sendmail from source to prevent it from attempting to use those calls). All you're left with is the need to keep ownership of files in the mail queue consistent and to keep nonprivileged users (which the bastion host shouldn't have anyway) from snooping on messages in transit. Creating a user just for Sendmail and making that user the owner of the queue directory should solve that problem.
Each of these tasks could probably be done in more secure ways, but this would require a major redesign and reimplementation of Sendmail, and nobody has yet stepped up to accept this challenge: among other reasons, out of fear that doing so would probably introduce new problems. Instead, we keep getting patch after patch for problem after problem, so that "the current Sendmail patch" has become something of a running joke in the network security community.
Sendmail has exhibited all of the types of general mailer vulnerabilities we discussed earlier. Patching has eliminated or reduced most of them; for example, it used to be easy to exploit command-line bugs in Sendmail as an unprivileged user, but modern versions strictly limit the options available to unprivileged users. However, as with all programs of any complexity, more problems are sure to be discovered. Also, patches for old problems have sometimes introduced new problems.
16.2.8. Other Freely Available SMTP Servers for UnixA number of other freely available SMTP servers are available for Unix. The best-known alternative SMTP servers for Unix are all designed to provide security, ease of configuration, and good performance. These include smail, Wietse Venema's Postfix, and Dan Bernstein's qmail. All of them provide a reasonable level of compatibility with Sendmail and offer similar (but not identical) features in the area of forwarding, aliasing, and mailbox delivery. All of the SMTP alternatives are arguably easier to customize than Sendmail and also support virtual domains, anti-relaying, and unsolicited bulk email protections. If you wish to replace Sendmail with one of these SMTP alternatives, we strongly recommend that you set up a trial for at least a month in order to gain operational experience, unless you are already familiar with the replacement. Users are fanatically unforgiving when it comes to bounced email.
Yet more freely available servers, designed for various purposes, are, of course, available for Unix. Few of them are designed specifically to provide security. You may have reasons to use servers not mentioned here, but you should be careful to evaluate the security that they provide.
188.8.131.52. smailsmail  was designed to be a secure replacement for Sendmail. It was originally designed and implemented by Ronald S. Karr and Landon Curt Noll, although it has now been passed on to other maintainers. smail is one of the earliest of the Sendmail replacements; it was released in 1987.
We are discussing smail version 3; there is an earlier mailer also called smail with a different lineage.smail can be used as a plug-in replacement for Sendmail as it uses many of the same command-line switches. In fact, it has been used as the SMTP mailer for several Linux distributions.
any of the security problems with Sendmail stem from its complexity, and smail was designed to incorporate only the most commonly used features of Sendmail. However, smail is still a monolithic program and requires the same security privileges as Sendmail. Furthermore, the addition of new features and different maintainers has resulted in a small number of security problems. Given the monolithic nature of smail, we cannot recommend using this package in a bastion host environment.
184.108.40.206. PostfixPostfix was designed and implemented by Wietse Venema as a highly secure and compartmentalized mailer. Rather than being a single program like Sendmail, Postfix is broken up into separate components, each with a specific task. The Postfix design also eliminates problems that can arise from Unix process inheritance; once a message is accepted by Postfix, it is processed by components that are not related to the Unix process ancestry of the submitter. Each component performs defensive data checking and is suspicious of all input data even if it has been read from another component of Postfix. All programs ought to be written in this way, but it is rarely done with enough care. Defensive data checking significantly reduces the chances of buffer overflow problems.
Postfix can be installed to just send mail, to send and receive mail alongside Sendmail, or to completely replace Sendmail. The configuration of Postfix is quite easy. Compatibility with Sendmail is good; it supports the use of user .forward files and can also be configured to use a system-wide custom local delivery agent (such as procmail ). Postfix is supplied with simple, straightforward, and clearly written instructions for compiling and installing Postfix and replacing Sendmail.
Postfix avoids most of the inherent difficulties with the design of Sendmail. It is the exact opposite of a monolithic problem, and does not use any setuid program. However, it does require a world-writable directory. This could cause problems on a multiuser system, but it can be eliminated by using a single program that uses the group equivalent of setuid, called setgid. If you don't want to run Sendmail on your bastion host mail server, then we recommend using either Postfix or smap/smapd, mentioned later in the Section 16.2.10, "Improving SMTP Security with smap and smapd" section.
220.127.116.11. QmailDan Bernstein wrote Qmail as a secure, reliable, and efficient replacement for Sendmail on typical Internet-connected Unix hosts. Qmail, like Postfix, is a compartmentalized mailer with separate programs for separate tasks. Unlike Postfix, it passes some information through process inheritance (one program starts another, which inherits information from the first). This reduces the separation between the programs.
Qmail is the least Sendmail-compatible SMTP replacement, although over time, it is becoming more compatible. As it is currently distributed, it handles forwarding and aliasing rather differently. In order to completely replace Sendmail and use the recommended mailbox format, you may also need to also replace the local delivery agent and possibly your mail user agents.
The different parts of Qmail run as different users, in order to make sure that each one has only the permissions it needs. Only one of them is setuid, and it is setuid to one of the special Qmail users, not to root. As long as the permissions and passwords for all of the Qmail users are correct, this is more secure than the widespread use of root made by Sendmail and smail.
16.2.9. Commercial SMTP Servers for UnixIn addition to the freely available SMTP servers mentioned previously, there are also a number of commercial SMTP servers for Unix, including the commercial version of Sendmail, Intermail, and Netscape's mail server. These products are mostly designed for volume, rather than for security and, with the exception of Sendmail, should be treated with the same skepticism you would apply to any other commercial network server. You should assume that they are vulnerable until proven otherwise. For more information on evaluating servers, see the comments on choosing security-critical programs in Chapter 13, "Internet Services and Firewalls". Ironically, because of the high-profile problems with Sendmail, the developers of the commercial Sendmail version are more security-conscious than any of the other developers of commercial mailers.
16.2.10. Improving SMTP Security with smap and smapdAn important step a firewall can take to improve security is to prevent attackers from speaking SMTP directly to a full-featured server and, instead, to use a substitute server. Fortunately, this is feasible. SMTP stands for "Simple Mail Transport Protocol", and it really is simple. An SMTP server needs to implement only about a half-dozen or so commands in the protocol in order to accept incoming mail.
If you are using Unix for handling electronic mail, you may want to consider using the smap package that is part of TIS FWTK as a "wrapper" for your SMTP server (particularly if you are using Sendmail). The package includes a pair of programs called smap and smapd.
smap is a very short, simple program intended solely to handle incoming SMTP connections; unlike Sendmail, which contains about 30,000 lines of code, smap contains only about 700 lines. The relative simplicity of smap means that, unlike Sendmail, it can be easily be examined and considered in its entirety for security problems. Furthermore, it's designed with least privilege and compartmentalization in mind. The smap program runs without root privileges. It is started by inetd, which takes care of binding it to port 25 before starting it, so that smap doesn't need to run as root to do that. It runs chrooted to a particular queue directory, and thus can't access anything outside that directory. All it does is accept incoming messages from the Internet via SMTP. It speaks the very minimum necessary set of SMTP commands, and it stores each message it receives in a separate file in the queue directory.
The second program, smapd, comes along regularly (typically once a minute) to process the files queued in this directory, normally by handing them to Sendmail for delivery.
The result of using this substitute SMTP server is that an attacker never has a direct SMTP connection to Sendmail or any other complex SMTP server. Such a system does not protect against data-driven security holes, but such holes would be extremely hard for any firewall system to guard against. Fortunately, data-driven holes in Sendmail seem to be very rare anyway; there has only been one instance to date.
This is covered in CERT Advisory 93:16. For information on obtaining CERT Advisories, see Appendix A, "Resources".You do give up certain capabilities by using the smap package because smap quite intentionally handles only the minimum possible set of SMTP commands. In particular, smap does not support any ESMTP features.
A potential drawback of smap, which has been incorporated into several commercial firewalls, is that the original version allowed mail relaying. Although mail relaying is not specifically a security problem, it can easily result in your firewall's running out of resources. If you are using smap, make sure that you have a version that prevents mail relaying.
16.2.11. biffMany SMTP mail servers for Unix implement a mail notification service called biff. If a user has biff turned on, then every time a message comes in, the user gets a notification that includes a message header summary and the first few lines of the message. The notification service uses UDP port 512 and is associated with the network daemon called comsat. Even though it uses a UDP port, it is not intended to be a network-available service; it normally gets packets only from processes running on the same host. This service should be disabled on all bastion hosts because they do not need to provide mail notification to their users (neither the mail nor the users should be local!). Similarly, bastion SMTP mail servers for Unix should be configured not to send the UDP packets. Since biff is not actually a network service, there's no reason to try to provide it through a firewall.
16.2.12. SMTP Support in Non-SMTP Mail SystemsSeveral popular mail systems are not based on SMTP. Lotus Notes and icrosoft Exchange, for instance, provide mail service, among other things, and use proprietary protocols to talk to their native clients. (They are discussed later in this chapter.) They also provide SMTP handling for Internet compatibility.
In general, non-SMTP mail systems are not particularly secure as SMTP servers. They are large systems to start with, designed for relatively secure environments and then improved for use on the Internet, which makes them vulnerable. Adding SMTP support to them merely increases the problem. In addition, their SMTP implementations tend to be at best eccentric and more often simply incorrect in their handling of obscure conditions, leading to various interoperability problems. If at all possible, use a dedicated SMTP mailer to speak and listen to the Internet (preferably Postfix, smap, or another security-oriented server).
16.2.13. SMTP Servers for Windows NTThe most widely used SMTP servers for Windows NT are Lotus Notes and Microsoft Exchange, which provide SMTP servers in addition to their other features. However, a number of SMTP servers are available for Windows NT that are designed primarily as SMTP servers. In general, dedicated SMTP servers are both more reliable and more secure than SMTP services added onto other mail systems. In the case of Windows NT SMTP servers, few are actually designed for security, and fewer still with the extensive history that Unix SMTP servers have. In general, they are full-fledged mail server systems including POP and/or IMAP servers, designed for maximum service rather than maximum security.
If you have a mixed environment, you will probably want to run your front-line SMTP server on Unix. If your environment is mostly or entirely Windows NT-based, there can be significant advantages to using a Windows NT-based SMTP server (aside from the normal administrative issues). Using a Windows NT-based server allows you to do virus checking on the SMTP server, for instance (this is possible with Unix servers, but the virus checkers tend to lag behind the versions that are available under Windows NT).
16.2.14. Summary of Recommendations for SMTP
Copyright © 2002 O'Reilly & Associates. All rights reserved.