<= IMG=20 alt=www.rackmount.com border=0 height=60=20 src="http://www2.linuxjournal.com/BannerAds/pcw/rackmount07-27.gif"=20 width=468>

Using Postfix for Secure SMTP = Gateways

Improve your site's e-mail hygiene and make life difficult for = spammers=20 and hackers.

by Mick Bauer and Brenno de Winter

E-mail is easily the most popular and important Internet service = today, which=20 has made it a popular target of cyber-criminals and spam-happy = miscreants.=20 Adding to the problem is the inescapable reality that configuring = sendmail, the=20 most commonly used Mail Transfer Agent (MTA), is complicated, = nonintuitive and=20 easy to get wrong.=20

Wietse Venema, intrepid developer of TCP wrappers and co-creator of = SATAN,=20 has come through for us again: his program, postfix, provides an=20 alternative to sendmail that is simpler in design, more modular, easier = to=20 configure and less work to administer. Equally important, it's been = designed=20 with scalability, reliability and sound security as fundamental = requirements.=20

This article is intended to bring you up to speed quickly on how to = use=20 postfix on your network as a secure means of receiving e-mail from and=20 delivering it to Internet hosts. In particular we'll focus on deploying = postfix=20 on firewalls, in DMZs and in other settings in which it will be exposed = to=20 contact with untrusted systems.=20

Is sendmail really that bad? That depends on what you need it to = do--the=20 learning curve may not be justified if your e-mail architecture is = simple. But=20 sendmail is unquestionably an extremely powerful, stable and widely = deployed=20 application that isn't going away anytime soon, nor should it. In fact, = The=20 Paranoid Penguin will probably feature a sendmail article some time in = the next=20 few months.=20

Background: Mail Transfer Agents

Both sendmail and postfix are Mail Transfer Agents. MTAs move e-mail = from one=20 host or network to another. These are in contrast to Mail Delivery = Agents, which=20 move mail within a system (i.e., from an MTA to a local user's mailbox, = or from=20 a mailbox to a file or directory). In other words, MTAs are like the = mail trucks=20 (and airplanes, trains, etc.) that move mail between post offices; Mail = Delivery=20 Agents are like the letter-carriers who distribute the mail to their = destination=20 mail boxes.=20

In addition to MTAs and MDAs, there are also various kinds of e-mail = readers,=20 including POP, POP3, and IMAP clients for retrieving e-mail from remote = systems.=20 These are also known as Mail User Agents, or MUAs. (There is no = real-life simile=20 for these, unless your mail is handed to you each day by a minion whose = sole=20 duty is to check your mail box now and then!) But we're not concerned = with these=20 or with MDAs, except to mention how they relate to MTAs.=20

By the way, if you still use UUCP, it's supported in postfix (and = continues=20 to be in sendmail, too); most MTAs support a variety of delivery = ``agents'',=20 almost always UUCP and SMTP at the very least. Still, for the remainder = of this=20 article we'll assume you're interested in using postfix for SMTP (Simple = Mail=20 Transfer Protocol) transfers.=20

SMTP Gateways and DMZ Networks

One very common use of SMTP, especially in organizations which use=20 other e-mail protocols internally, is on an Internet e-mail = gateway.=20 Since SMTP is the lingua franca for Internet e-mail, there must = be at=20 least one SMTP host on any network that needs to exchange e-mail over = the=20 Internet. In such a network, the SMTP gateway acts as a liason between = non-SMTP=20 mail servers on the inside and SMTP hosts on the outside.=20

This ``liason'' functionality in and of itself isn't as important as = it once=20 was; the current versions of Microsoft Exchange, Lotus Notes, and many = other=20 non-SMTP-based e-mail server products have no problem communicating with = SMTP=20 servers directly. But there are still reasons to have all inbound (and = even=20 outbound) e-mail arrive at a single point, the chief reason being = security.=20

There are two main security benefits to using an SMTP gateway. First, = it's=20 much easier to secure a single SMTP gateway from external threats than = it is to=20 secure multiple internal e-mail servers. Second, separating Internet = mail from=20 internal mail allows one to move Internet mail transactions off the = internal=20 network entirely. The logical place for an SMTP gateway is in a DMZ=20 (``Demilitarized Zone'') network, separated from both the Internet and = the=20 internal network by a firewall.=20

As with DNS, FTP, WWW and any other publicly accessible service, the = more=20 protection you can place between potential hackertargets and your = internal=20 network, the better. Adding an extra NIC to your firewall, keeping = public=20 services in a separate network, is one of the cheapest and most = effective ways=20 of doing this--as long as you configure the firewall to carefully = restrict=20 traffic to/from the DMZ). It's also good risk management; in the = (hopefully)=20 unlikely event that your web server, for example, is compromised, it = won't=20 become nearly as convenient a launch pad for attacks on the rest of your = network.=20

(For additional information on the DMZ technique of firewalling, see = the=20 article Securing DNS and BIND, page 92 of this issue.)=20

Thus, even organizations with only one e-mail server should still = consider=20 adding an SMTP gateway, even if that e-mail server already has SMTP=20 functionality.=20

But what if your firewall is your FTP server, e-mail server, = etc.?=20 Although the use of firewalls for any service hosting is scowled upon by = the=20 truly paranoid, this is common practice for very small networks (e.g., = home=20 users with broadband Internet connections). And, in this foul-weather=20 paranoiac's opinion, BIND and postfix pose much less of an exposure for = a=20 firewall than other service applications.=20

For starters, DNS and SMTP potentially involve less direct contact = between=20 untrusted users and the server's file system. (I say ``potentially'' = because=20 it's certainly possible, with badly written or sloppily configured = software, to=20 create extremely insecure DNS and SMTP services.) In addition, both BIND = and=20 postfix have ``chroot'' options and run as unprivileged users, two = features that=20 help reduce the danger of either service being used to somehow gain root = access=20 (we'll discuss both of these options in depth shortly.)=20

Postfix Architecture: How Does Postfix Work?

To understand how postfix works, it's useful to consider its = background. The=20 main purpose for postfix's existence is sendmail's complexity. Postfix = is a=20 full-featured MTA, and therefore its core functions are the same as any = other's.=20 But postfix was written with unusual attention to:=20

• Security. Postfix was designed with security as a = fundamental=20 requirement rather than as an afterthought. It's obvious that Mr. = Venema has=20 taken the lessons of history (as chronicled by CERT, bugtraq, et al.) = very=20 much to heart. For example, the system doesn't trust any data, = regardless of=20 its source. And with least privilege in a chrooted jail (see below), = risks are=20 reduced. Furthermore, protective measures against buffer overflows and = other=20 user-input attacks have been implemented. If something still fails, = postfix's=20 protection mechanism tries to prevent any of the processes under its = control=20 from gaining rights they shouldn't have. Since postfix is comprised of = many=20 different programs that function without a direct relationship to each = other,=20 if something goes wrong, the chance that such a problem can be = exploited by an=20 attacker is minimized. Of course, we all know that no system is 100% = secure;=20 the goal must be to minimize and manage risks. Postfix is definitely=20 engineered to minimize security risks.=20
• Simplicity and compatibility. Postfix has been written in = such a=20 way that setting it up ``from scratch'' can take as little as five = minutes.=20 When you want to replace sendmail or other MTAs, it's even better: = postfix by=20 default can use the old configuration files!=20
• Robustness and stability. Postfix was written with the = expectation=20 that certain components of the mail network (the Local Area Network, = the=20 Internet uplink, the local interfaces, etc.) will occasionally fail. = By=20 anticipating things that can go wrong at either end of any given = transaction,=20 postfix is capable of keeping the server up and running in many (if = not most)=20 circumstances. If, for instance, a message cannot be delivered, it is=20 scheduled to be delivered later, without immediately initiating a = continuous=20 retry.

• Maildrop queue. Mail that is delivered locally on the = system is=20 accepted in the Maildrop queue. Here, the mail is checked for proper=20 formatting (and fixed if necessary) before being handed to the = Incoming queue.=20
• Incoming queue. The Incoming queue receives mail from other = hosts,=20 clients or the Maildrop queue. As long as e-mail is still arriving and = as long=20 as postfix hasn't really handled the e-mail, this queue is the place = where the=20 e-mails are kept.=20
• Active queue. The Active queue is the queue that is used to = actually deliver messages and therefore has the greatest potential = risk of=20 something going wrong. This queue has a limited size, and messages = will be=20 accepted only if there is space for them. That means e-mail in the = Incoming=20 and Deferred queues have to wait until the Active queue can accept = them.=20
• Deferred queue. E-mail that cannot be delivered is placed = in the=20 Deferred queue. This prevents the system from continuously trying to = deliver=20 e-mail and keeps the Active queue as short as possible in order to = give newer=20 messages priority. This also enhances stability. If the MTA cannot = reach a=20 domain, all the e-mail for that domain is placed in the = Deferred queue,=20 so that those messages will not needlessly monopolize system = resources. Retry=20 is scheduled with an increasing waiting time. When the waiting time = expires,=20 the e-mail is again placed in the Active queue for delivery; the = system keeps=20 track of retry history.

Postfix for the Lazy: A Quick and Dirty Startup Procedure

And now the part you've been waiting for (or have skipped directly = to):=20 postfix setup. Like sendmail, postfix uses a ``.cf'' text file as its = primary=20 configuration file called main.cf. However, ``.cf'' files in = postfix=20 use a simple ``parameter=$value'' syntax. What's more, these files are = extremely=20 well commented and use highly descriptive variable names.=20

In fact, if your e-mail needs are simple enough, it's probably = possible for=20 you to figure out much of what you need to know by editing = main.cf and=20 reading its comments as you go.=20

For many users, this is all one needs to do to configure postfix on = an SMTP=20 gateway:=20

1. Install postfix from a binary package via your local package tool = (rpm,=20 etc.) or by compiling from source and running postfix's = INSTALL.sh=20 script.=20
2. Open /etc/postfix/main.cf with the text editor of your choice.=20
3. Uncomment and set the parameter myhostname to equal your = server's=20 fully qualified domain name (FQDN), e.g., ``myhostname ==20 buford.dogpeople.org''.=20
4. Uncomment and set the parameter mydestination as follows, = assuming this is the e-mail gateway for one's entire domain: =

mydestination = $myhostname, localhost.$mydomain, =
$mydomain

1. Save and close main.cf.=20
2. If desired, add a line to /etc/aliases diverting root's mail to a=20 less-privileged account, e.g., root: mick. This is also the = place to=20 map aliases for users who are served by internal mail servers (for = example,=20 mick.bauer: mbauer@secretserver.dogpeople.org). When you are = done=20 editing and/or adding aliases, save the file and enter the command=20 newaliases to convert it into a hash database.=20
3. Execute the command postfix start.

(NOTE: While this may be enough to get postfix working, it is = not=20 enough to secure it. Don't stop reading yet!)=20

The Quickness and Dirtiness Explained

As cool as that was, it may not have been enough to get postfix to do = what=20 needs to be done for your network. And even if it was, it behooves you = to dig a=20 little deeper: ignorance nearly always leads to bad security. Let's take = a=20 closer look at what we just did, and then move on to even niftier = postfix=20 tricks.=20

First, why did so little information need to be entered in main.cf? = The only=20 thing we added to it was our fully qualified domain name. In fact, = depending on=20 how your machine is configured, it may not have even been necessary to = supply=20 that!=20

This is because postfix uses system calls such as = gethostname to=20 glean as much information as possible directly from your kernel. If = given the=20 fully qualified domain name of your host, it's smart enough to know that = everything past the first ``.'' is your name-domain, and it sets the = variable=20 mydomain accordingly.=20

You may need to add additional names to mydestination if = your server=20 has more than one FQDN (that is, multiple ``A'' records in your domain's = DNS).=20 For example, if your SMTP gateway doubles as your public FTP server, and = thus=20 has the name ``ftp'' associated with it in addition to its normal host = name,=20 your mydestination declaration might look something like this:=20

mydestination = $myhostname, localhost.$mydomain, =
ftp://www.$mydomain, $mydomain

There were two other interesting things we did in the ``quick and = dirty''=20 procedure. One was to start postfix with the command postfix = start.=20 Just as BIND uses ndc to control the various processes that = comprise=20 BIND, the postfix command can be used to manage postfix. Like = BIND,=20 postfix is actually a suite of commands, d=E6mons and scripts rather = than a single=20 monolithic program.=20

The most common invocations of the postfix command are = postfix=20 start, postfix stop and postfix reload. Start and stop are = obvious; reload causes postfix to reload its configuration files without = stopping and restarting. Another handy one is postfix flush, = which=20 forces postfix to immediately attempt to send all queued messages. This = is=20 particularly useful after changing a setting that you think may have = been=20 causing problems--in the event that your change worked, all messages = delayed by=20 the problem go out immediately. They'd go out regardless, but not as = quickly.=20

The other thing we did was to add a line to /etc/aliases to divert = root's=20 e-mail to an unprivileged account. This is good healthy paranoia: we = don't want=20 to have to log in as the superuser for mundane activities such as = viewing system=20 reports, which are sometimes e-mailed to root. Be careful, however: if = your=20 unprivileged account uses a ``.forward'' file to forward your mail to = some other=20 system, you may wind up sending administrative messages over public = bandwidth in=20 clear text!=20

Aliases Revealed

As alluded to in the quick and dirty procedure, aliases are also = useful for=20 mapping e-mail addresses for users who don't actually have accounts on = the SMTP=20 gateway. This practice has two main benefits. First, most users prefer=20 meaningful e-mail names and short host /domain names, e.g.,=20 ``john.smith@acme.com'' rather than = ``jsmith023@mail77.midwest.acme.com''.=20 Second, you probably don't want your users connecting to and storing = mail on a=20 publicly accessible server. Again, common sense tells us that any server = the=20 unwashed masses can commune with must be kept at arm's length. The = greater the=20 separation between public servers and private servers, the better. (And = don't=20 forget, POPmail passwords are transmitted in clear text!)=20

Still another use of aliases is the maintenance of mailing = lists. An=20 alias can point to not only an address or comma-separated list of = addresses, but=20 also to a mailing list. This is achieved with the = :include:tag--without=20 this, postfix will append mail to the file specified rather than = using=20 the file to obtain recipients. (This is a feature, not a bug; it's = useful=20 sometimes to write certain types of messages to a text file rather than = to a=20 mailbox.)=20

Here's part of an example alias file that contains all of these types = of=20 mappings:=20

postmaster:	root<\n>
mailer-daemon:	root
hostmaster:	root
root:		bdewinter
mailguys:	bdewinter,mick.bauer
mick.bauer:	mbauer@biscuit.stpaul.dogpeople.org
clients:	:include:/etc/postfix/clientlist.txt
spam-reports:	/home/bdewinter/spambucket.txt

Don't forget to run either newaliases or, hipper still,=20 postalias /etc/aliases anytime you edit aliases. The = postalias=20 command is hipper because it can accept any correctly formatted = alias=20 file as its input. Both commands compress the alias file into a database = file=20 that can be searched repeatedly and rapidly each time a destination = address is=20 parsed; neither postfix nor sendmail directly use the text version of=20 aliases.=20

If you have a large number of users and/or internal mail servers, = alias-file=20 updates lend themselves to automation, especially via Secure Shell (ssh) = and=20 Secure Copy (scp). Using scp with null-passphrase RSA (or DSS/El Gamal) = keys,=20 your internal mail servers can periodically copy their local alias files = to the=20 SMTP gateway, which can then merge them into a new /etc/aliases followed = by=20 postalias /etc/aliases. (Unfortunately, telling you exactly = how=20 to use scp/ssh is beyond the scope of this article.) This practice is = especially=20 useful in large organizations where different people control different = mail=20 servers: day-to-day e-mail account administration can be kept = decentralized.=20

Keeping out Unsolicited Commercial E-mail

Junk mail is one of the most common and annoying types of e-mail = abuse.=20 Postfix offers protection against UCE (Unsolicited Commercial E-mail) = via a=20 couple of settings in main.cf. Some caution is in order, however: = there's a fine=20 line between spam and legitimate dissemination, and it's entirely = possible that=20 even modest UCE controls will cause some legitimate (i.e., desired) mail = to be=20 dropped.=20

Having said that, for most sites this is an acceptable risk = (avoidable, too,=20 through end-user education), and we recommend that at a minimum, = you set=20 the following in main.cf:=20

• smtpd_recipient_limit. This setting indicates how many = recipients=20 may be addressed in the header of a single message. Normally, such a = number=20 should not exceed something like 500. It would be extreme to receive = an e-mail=20 that has 500 recipients and was not being sent to a mailing list.=20
• smtpd_recipient_restricitons. Not every e-mail that arrives = at your=20 server should be accepted. This parameter instructs postfix to check = each=20 message's recipient-address base on one or more criteria. One of the = easiest=20 to maintain is the access database. This file lists domains, = hosts,=20 networks and users who are allowed to receive mail from your server. = To enable=20 it: (1) set check_recipient_access = hash:access; (2) = create=20 /etc/postfix/access (do a man 5 access for format/syntax); = and (3)=20 run postmap hash:/etc/postfix/access to convert the file into = a=20 database. Repeat step (3) each time you edit /etc/postfix/access.=20
• smtpd_sender_restrictions. By default postfix will accept = SMTP=20 connections from everybody, potentially exposing your server to SMTP = relaying,=20 a method often used for UCE perpetrators who wish to hide their = identities by=20 ``bouncing'' their messages off unsuspecting SMTP relayers. If this = occurs,=20 it's possible and even likely that other servers will reject e-mail = from your=20 domain(s). Other protection mechanisms lie in the fact that it is = always wise=20 to check the sender against DNS. Although this costs some performance, = it=20 makes it harder to send the information from a faulty sender e-mail = address.=20 See the file /etc/postfix/sample-smtpd.cf for a list of possible list = options=20 for this parameter. Note that hash:access is one of them; the = access database can be used not only to allow/disallow = particular=20 recipients, but senders as well. For a complete list of anti-UCE = parameters=20 and their exact syntax see /etc/postfix/sample-smtpd.cf.

Hiding Internal E-mail Addresses by Masquerading

In order to prevent giving out information that serves no purpose to=20 legitimate external parties, it is wise to set in the main.cf file the = parameter=20 masquerade_domains = $mydomain (remember, = ``$mydomain''=20 refers to a variable). If you wish to make an exception for mail sent by = ``root'' (probably a good idea), you can set the parameter=20 masquerade_exceptions = root. This will cause internal = host=20 names to be stripped from FQDSes in ``From'' addresses of outbound = messages.=20

Running Postfix in a chroot Jail

Now we come to one of the groovier things we can do to secure = postfix:=20 running it in a ``chroot jail''. chroot is a UNIX command that = confines=20 the ``chrooted'' process to a specified directory; that directory = becomes ``/''=20 for that process. This usually requires you to first create copies of = things=20 needed by the process but normally kept elsewhere. For example, if the = process=20 looks for ``/etc/mydaemon.conf'' upon startup but is being chrooted to=20 ``/var/mydaemon'', the process will actually look for=20 ``/var/mydaemon/etc/mydaemon.conf''.=20

The advantage to chrooting should be obvious: should a = chrooted-postfix=20 process become hijacked somehow, the attacker will find himself in a = ``padded=20 cell'' from which (hopefully) no sensitive or important system files or = data can=20 be accessed. This isn't a panacea, but it significantly. increases the=20 difficulty of exploiting postfix.=20

Happily, the preparations required to chroot postfix are provided in = a=20 subdirectory of the postfix documentation called ``examples''. These = files=20 aren't really shell scripts: they're suggested sequences of commands.=20

Better still, some binary distributions of postfix have installation = scripts=20 that automatically make these preparations for you after installing = postfix. In=20 SuSE, for example, the postfix RPM package runs a script that creates a = complete=20 directory tree for postfix to use when chrooted (etc, usr, lib, and so = forth) in=20 /var/spool/postfix, with the appropriate ownerships and permissions.=20

In addition to ``provisioning'' postfix's chroot jail, you need to = edit=20 /etc/postfix/master.cf to toggle the postfix d=E6mons you wish to run = chrooted=20 (i.e., put a ``y'' in the ``chroot'' column of each d=E6mon to be = chrooted). Do=20 not, however, do this for d=E6mons whose ``command'' column = indicates that=20 they are of type ``pipe'' or ``local''. Some binary-package = distributions toggle=20 the appropriate d=E6mons to chroot automatically during postfix = installation=20 (again, SuSE does).=20

After configuring the chroot jail and editing master.cf, all you need = to do=20 is start postfix the way you normally would: postfix start. = Postfix's=20 master process handles the actual chroot-ing.=20

Conclusion

That's more than enough information to get you started. May your mail = arrive=20 promptly and the spamming filth stay out!=20

Resou= rces=20

=20

Mick Bauer is security practice lead at the Minneapolis = bureau=20 of ENRGI, a network engineering and consulting firm. He's been a Linux = devotee=20 since 1995 and an OpenBSD zealot since 1997, taking particular = pleasure in=20 getting these cutting-edge operating systems to run on obsolete junk. = Mick=20 welcomes questions, comments, and greetings sent to mick@visi.com. =

Brenno de Winter, 28, is the Linux-focused president of = De=20 Winter Information Solutions. He started programming at the age of = nine. In=20 his daily routine he is involved in UNIX/Linux, databases, security,=20 telephony-over-IP presentations, consulting and training. He's active = in the=20 Polder Linux User Group, has contributed to several GPL projects, = including=20 GnuPG, MySQL and TWIG, and is in the process of creating a brand-new = project=20 himself as well.

LinuxSupport.org.uk was designed and built by Paul Vigay. In Pauls absence this site has now been taken over and updated by Bob Ruskin. Latest Updates | Copyright | Disclaimer | Privacy policy