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).

[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".

1. Use DNS Mail Exchange (MX) records to specify that all your incoming mail should be directed to your bastion host(s).[58]

   [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".

2. Configure the mailer on the bastion host to check the destination address on mail it receives. If the mail is being sent from an internal host to an external host, the bastion host should process the mail as usual; if the mail is to an internal host, the bastion host should simply pass the mail to an internal mail server for processing, rather than attempt to deliver the mail itself. (If the mail is from an external host to an external host, the mailer should reject it altogether; see the section on preventing mail relaying, earlier in this chapter.)

3. Configure your internal systems to send all outgoing mail to the bastion host.

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).

• Listen on port 25 (a privileged port) for incoming SMTP connections

• Operate as a particular user to read .forward files and :include: alias files owned by that user, and to run programs specified by those files

• Execute certain kernel system calls that (in some versions of Unix) are restricted to programs running as root (for example, to determine the system load in order to decide whether enough capacity is left to process mail)

• Protect files in the mail queue (i.e., messages in transit) from snooping by unprivileged users

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.

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".

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.

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.

• Use the normal store-and-forward features of SMTP to send all incoming and outgoing mail through a bastion host.

• Use packet filtering to restrict SMTP connections from external hosts to just the bastion host you use as a mail server.

• Use packet filtering to restrict SMTP connections from the bastion host you use as a mail server to a specific internal server or set of servers.

• Use Postfix or smap instead of Sendmail as the SMTP server on the bastion host you use as a mail server and probably on your internal mail server as well.

• Keep up to date with patches on delivery agents and user agents.

• Educate your users concerning mail-based scams, such as instructions to run particular programs or to change their passwords to some specified string.