6.2. Mail Architecture

So far, we've discussed three classes of attacks against mail servers: those that exploit the application to gain access to the operating system, those that leverage poor configuration in the mail system to provide for arbitrary mail delivery, and those that use the mail delivery systems as a carrier for malware. In order to defend against these attacks, we must again abide by the defense-in-depth rule for systems security. What better place to start than with the architecture of the systems involved?

6.2.1. Protect the Operating System

Attacks seeking access to the operating system may use any piece of mail software that accepts input from users, either directly or indirectly. Architecturally, this is difficult to defend against. Your best bet is to tightly restrict who has access to the interfaces that expect direct user input. These include protecting the services that provide mail transport (Sendmail, Postfix, or qmail listening on port 25) and mail access (software that provides IMAP/POP).

Another avenue for direct user interaction is through a local or NFS mounted filesystem. Note that a mail server that allows user logins falls into the "Workgroup" class of system described in Chapter 3 and will be difficult to secure. If users demand mail delivery to local systems, consider using .forward files, aliases, or making them use fetchmail to redirect mail to workstations. This leaves critical mail servers with administrator-only access while providing users access to mail on their local workstations.

Let's start with a mail system consisting of one machine that listens for incoming connections on port 25 and also allows IMAP and POP mail access on ports 110 and 143 to mail content on local disks. What software is installed on this system is fairly important. Some organizations have little choice and must run Microsoft Exchange, Novell Groupwise, or some other groupware platform to satisfy external requirements. Other organizations are tightly bound to Sendmail or may have other legacy internal mail systems in place.

The easiest way to mitigate some of the risks associated with allowing users on the Internet open access to your mail system is to control mail flow and access, as shown in Figure 6-1.

Figure 6-1. Simple mail architecture

This example outlines an internal mail server (or servers) and an external "relay" server, which does nothing more than accept inbound mail and pass it to the internal system. The relay provides a single point of interaction with outside users that can be tightly controlled and diligently maintained, thwarting attacks coming in from the Internet.

Of course, most successful attacks against systems in general do not come in from the Internet but from internal users. Keeping external interfaces up to date and patched is vital as the number of externally originating attacks will probably be higher. Forgetting the risk posed by internal users, however, will likely get you into trouble with the first attack.

Both the mail relay and the internal mail server now provide mail transport: they both listen on port 25 for incoming connections and do something with received messages. If you ensure both systems are running patched versions of mail transport software, attacks aimed at exploiting the service to gain access to the operating system are likely to fail.

6.2.2. Avoid Being an Open Relay

Any competent mail administrator would swear that he would never be caught administering an open relay. While he might not intentionally deploy such a system, accidents do happen. A simple mistake, or a series of configuration changes, may result in an open relay if you don't verify the effects of each change. With any combination of networked systems, it's nearly impossible to look at a single mail server and say, "I am not an open relay." You must look at the mail flow in your organization and periodically audit configuration to ensure mail can't flow from external senders to external recipients.

Three strategies can help you avoid an open relay configuration. A controlled and documented mail flow, as shown in Figure 6-2, is a good start. Strict change control procedures with regression testing reduce the likelihood of erroneous configuration. Regular auditing ensures compliance with the desired configuration.

Figure 6-2. Strict enforcement of mail flow through key systems

When the time comes to audit, the following steps help reduce the risk of being an open relay:

1. Ensure all systems on your network send mail directly to a designated mail server. This means internal systems should send mail to the internal mail server, and systems on your DMZ should send mail to the mail relay.

2. Ensure firewall restrictions prevent any systems outside the organization or on the DMZ from reaching the internal workgroup mail server. Likewise, ensure the mail relay accepts inbound connections on port 25 from the Internet, and bi-directional communication on port 25 with internal mail server and nothing else!

3. Ensure your mail servers do not implicitly trust any messages that originate on other systems. Most mail transport software will accept a list of IP addresses or address/mask combination describing systems for which the server should automatically accept and relay mail. List no other addresses than those local to the mail server in question.

4. Ensure your mail servers are aware of which domain(s) are considered "internal," and mandate that either the recipient or the sender must be a part of this domain.

These steps work for the simple mail architecture shown in Figure 6-2. More complex configurations will of course require a different procedure, but the mail flow guidelines should apply universally. Still, open relays aren't the only possible problem. Any scripts on web sites that accept POST or GET data containing a recipient should be subjected to great scrutiny.

6.2.3. Stop Unwanted Mail

Spam, viruses, and worms are a bane to administrators and users alike. At best, these messages consume bandwidth and resources and at worst, they cause network outages and system failures. Most administrators who provide user support have to explain to users that no, in fact, their user account has not been hijacked to send spam that there is no greater security in an email header than there is on the return address of a snail-mail envelope (more on this topic later).

Protecting your infrastructure from unwanted mail is tricky. You must configure carefully and set thresholds to block the greatest amount of illegitimate mail, while allowing legitimate mail to pass. The extent to which you can be authoritarian will depend on your organization's tolerance for lost (or bounced) legitimate mail from false positives. In general, there are three approaches you can take with unwanted mail:

Quarantine

You may quarantine messages you feel are illegitimate or harmful into a malware repository. This repository needs periodic audits to delete existing messages or allow legitimate mail through. Alternately, you could set up a time-limited quarantine that automatically purges messages after a fixed period of time. This allows for more flexibility and requires less administration.

Reject

One of the most popular ways of dealing with suspect mail is to reject it. This notifies the sender that the message did not look legitimate and therefore was returned. While this is easier on the administrator, the number of messages traveling back to nonexistent/fraudulent senders may start to clog your mail queue. What's worse, most mail users pay no attention to messages from MAILER-DAEMON saying 550 Content rejected. Contact [e-mail] for assistance. Instead, they call the intended recipient and accuse them of having broken mail servers.

Tag

Often used in combination with a rejection strategy, some organizations use software that marks or tags suspect messages letting users' MUAs filter based on the tags in the message header or body. This approach uses thresholds set by the administrator, the user, or both. In some cases, users are not willing to concern themselves with tuning their spam filter, thus combination approaches with "opt-in" user-configured filtering work well.

6.2.3.1 Content filtering with SpamAssassin

SpamAssassin uses a system of weighted rules to compute the likelihood that a particular message is spam. This provides a far more effective means of filtering mail content than by specifying "bad strings" or "suspicious headers" and so on in a flat text file. The key advantage is that the SpamAssassin rules are updated on a regular basis. Unless your full-time job is to observe new spam and update your personal rules file, SpamAssassin will probably provide more timely rule updates.

SpamAssassin is a fairly substantial and configurable mail filtering application. We don't cover the intricacies of installing and configuring SpamAssassin here. Visit the project home page at http://spamassassin.apache.org/ to learn more.

SpamAssassin is easy to install on both FreeBSD and OpenBSD systems through the port in mail/p5-Mail-SpamAssassin. There are two main ways to make SpamAssassin parse incoming mail in conjunction with Sendmail: use procmail or use a SpamAssassin milter. Both are available in the ports tree on OpenBSD and FreeBSD systems. Postfix may be coupled with SpamAssassin in three main ways: using procmail, defining SpamAssassin as a content filter, or using amavisd-new (a high performance MTA and content checker interface).

6.2.3.2 Arbitrary content filtering

Arbitrary content filtering gives the administrator the ability to reject or drop mail by matching some string in the header or body of a message. While SpamAssassin does a decent job of tagging incoming spam, certain situations may arise where arbitrary filtering may be appropriate:

• Having set your SpamAssassin threshold to 5.0, you notice after a few months or a year that you have not seen any false positives above a 12.0 threshold. You need a way to block all messages SpamAssassin marks with a value greater than 12.

• A new piece of malware is announced on a mailing list to which you are subscribed. It's particularly insidious and spreads quickly but always has one of three subject lines. You need to make sure this virus does not get past your mail relay, and you need to do it yesterday.

• You want to block messages with certain attachments outright.

For these "quick and dirty" situations, content filtering based on administrator-configured pattern-matching is a good choice.

6.2.3.3 DNS real-time blacklists (RBLs)

In addition to rejecting based on headers or content, mail can be rejected based on the host from which the connection is being made. We have thrown around the word "blacklist" a few times in this chapter but have not yet described what it means. Blacklists, DNS blacklists, or real-time blacklists (RBLs), are essentially lists of systems known to be open relays or known to have sent spam in the past. These blacklists can be retrieved or accessed over the Internet through DNS. Mail servers are often configured to verify every incoming connection to ensure it is not from a blacklisted server if it is, message transmission is denied. The original RBL site, http://www.mail-abuse.com/, offers a subscription-based service (it costs money) but is one of the more reputable blacklist services available. Other trustworthy RBL providers include: Spam Cop, the Open Relay Database, and RFC-ignorant.org. See the Section 6.11 at the end of this chapter for links to these public service RBL providers.

Do some research before you start using any RBL; they list sites for different reasons. RFC-ignorant, for instance, will list any site that fails to obey the rules defined by the mail-related RFCs. This may block more than you bargained for.

The facilities available to us on FreeBSD and OpenBSD systems to accomplish these tasks are diverse. We'll go through them in the final stages of mail software configuration. One important thing to remember is that you shouldn't rely on only one way of stopping unsolicited mail. These approaches complement each other, they aren't mutually exclusive.