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.
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.
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).
Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
---|---|---|---|---|---|---|---|
In | Ext | Int | TCP | >1023 | 25 |
[57]
|
Incoming mail, sender to recipient |
Out | Int | Ext | TCP | 25 | >1023 | Yes | Incoming mail, recipient to sender |
Out | Int | Ext | TCP | >1023 | 25 | [57] | Outgoing mail, sender to recipient |
In | Ext | Int | TCP | 25 | >1023 | Yes | Outgoing mail, recipient to sender |
[57]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.
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".
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.
[58]For a detailed discussion of MX records, how they work, and how to use them, see the books TCP/IP Network Administration, by Craig Hunt (O'Reilly & Associates, 1998) and DNS and BIND, by Paul Albitz and Cricket Liu (O'Reilly & Associates, 1998). Both of these books are also available in specialized versions for Windows NT; further details are in Appendix A, "Resources".
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).
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.
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.
[59]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.
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.
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.
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.[60]
[60]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.
[61]"Biff" is not an acronym; it is the name of the original programmer's dog, which used to bark at the mailman.
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).
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).
Windows NT systems, like Unix systems, should be set up with a security-conscious server as the Internet-visible server, which then passes the mail to a full-featured server on the inside.