Hardening Sendmail

Mick examines sendmail's security controversies and builds an SMTP gateway for handling internet mail.
Red Hat Sendmail Preparation

If you're a Red Hat user, you have only one step prior to configuring sendmail: edit /etc/sysconfig/sendmail so that the variable DAEMON is set to “yes”. This will tell the startup script /etc/init.d/sendmail to start sendmail as a dæmon at boot time.

Configuring Sendmail

And now, at last, we configure sendmail to act as our domain's SMTP gateway. What follows applies to any installation of sendmail 8.9 or higher (you shouldn't in any circumstances run 8.8).

The simplified method of generating sendmail configurations (sendmail.cf and accompanying files) consists of these steps:

  1. Enable needed features in sendmail.mc.

  2. Set up domain-name masquerading, if needed, in sendmail.mc.

  3. Run m4 to generate sendmail.cf from sendmail.mc.

  4. Configure delivery rules by editing mailertable.

  5. Configure relaying rules by editing access.

  6. Configure local user-aliases in aliases.

  7. Convert mailertable, access and aliases to databases.

  8. Define all local hostnames in local-host-names.

  9. (Re)start sendmail.

Notable Settings in sendmail.mc

The first and probably longest task in setting up an SMTP gateway is generating /etc/sendmail.cf. This is done most easily by editing /etc/mail/sendmail.mc (or on SuSE systems, /etc/mail/linux.mc—it may be different on other distributions).

Depending on which Linux distribution you use, configuration information for sendmail.mc can be found in /usr/share/doc/sendmail/README.cf (Red Hat and its derivatives), /usr/share/sendmail/README (SuSE) or some variant thereof. I don't have enough space to describe the syntax of the many settings in this file in detail. We will, however, look at some that are useful for security and for modularizing our configuration a bit.

In addition to sendmail.cf itself, we can configure sendmail to read several other files for configuration information. This is useful for two reasons. First, editing sendmail.cf directly is unpleasant and even regenerating it from sendmail.mc isn't always desirable. Second, if your SMTP gateway has multiple administrators with varying privileges, you may wish to keep sendmail.mc and sendmail.cf locked down but allow other administrators to edit user aliases or mail delivery rules (i.e., /etc/mail/access and /etc/mail/mailertable, respectively).

The most useful external configuration files to enable are mailertable, which defines local mail-delivery rules; virtusertable, which defines virtual domain mappings on a per-user and per-domain level; and access, which defines which hosts may use the server as an SMTP relay.

The sendmail.mc directives for enabling these files are shown below:

FEATURE(`mailertable',`hash -o
        /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o
        /etc/mail/virtusertable.db')dnl
FEATURE(`access_db',`hash -o
        /etc/mail/access.db')dnl

(Note that the mailertable and access_db features are enabled by default under Red Hat, but that virtusertable must be added manually.)

Each of these lines tells sendmail to reference the specified file (although the access database is called access, not access_db), to use a hash database and the path of the respective file. We'll see how to use these files shortly, but first we've got a few more things to attend to in sendmail.mc.

If your users' e-mail addresses are generic to your domain rather than specific to the hosts they log on to, for example, mick@polkatistas.org rather than mick@myron.polkatistas.org, you probably want the From: fields of their outbound e-mail to reflect this. (Receiving e-mail addressed to those generic names requires user aliases—see below.)

Following are some sendmail.mc lines that tell our example SMTP gateway to rewrite the From: fields of polkatistas.org's users in this manner. All the lines in the example below must be added (or uncommented):

MASQUERADE_AS(`polkatistas.org')dnl
MASQUERADE_DOMAIN(`.polkatistas.org')dnl
EXPOSED_USER(`root')dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`masquerade_envelope')dnl

The MASQUERADE_AS directive specifies the fully qualified domain name you wish to appear in applicable From: addresses. The MASQUERADE_DOMAIN directive specifies the hosts to which MASQUERADE_AS is applicable. Note that the “.” preceding polkatistas.org indicates that all hostnames with this domain name are to be masqueraded.

EXPOSED_USER specifies a user name for whom the From: address should not be masqueraded. root is a popular candidate for this because e-mail from root often contains alerts and warnings; if you receive one, you generally want to know which host sent it.

The feature masquerade_entire_domain causes MASQUERADE_DOMAIN to be interpreted as an entire domain rather than a hostname; masquerade_envelope applies the masquerading not only to the SMTP header but to the envelope as well.

Four other directives, one logistical and the other three security-related, are shown in Listing 1. The always_add_domain feature is enabled by default under Red Hat and SuSE; use_cw_file and smrsh are enabled in Red Hat but not SuSE; confSAFE_FILE_ENV always must be defined manually.

Listing 1. Some More Sendmail Features

The always_add_domain feature simply forces the local host's domain name to be appended to any e-mail originating from a host that identifies itself without a domain. For example, if the SMTP gateway receives mail from the user “bobo” on a host identified only as “whoopeejohn”, sendmail will rewrite the From: field to read bobo@whoopeejohn.polkatistas.org rather than bobo@whoopeejohn (but of course masquerading directives still apply).

The use_cw_file feature tells sendmail to refer to the file /etc/mail/local-host-names for a list of hostnames sendmail should consider local. The file /etc/mail/local-host-names is a text file containing hostnames listed one per line. Suppose our example SMTP gateway receives e-mail not only for the domain polkatistas.org, but also tubascoundrels.net. If our gateway's hostname is “mail”, then its local-host-names file will look like this:

localhost.localdomain
mail.polkatistas.org
mail.tubascoundrels.net

The third feature enabled in Listing 1 is smrsh, the sendmail restricted shell. This is an important security control that restricts the commands that may be executed from a user's .forward file.

The fourth line in Listing 1 tells sendmail to set sendmail.cf's SafeFileEnvironment variable to, you guessed it, some subdirectory of / that sendmail will chroot to (sort of). Actually, this only will happen when sendmail writes files. If you think about it, though, this 50% chroot makes sense: file-writes are what we're probably most worried about, and creating this sort of chroot environment is a lot simpler than your typical chroot jail (which must contain copies of every file hierarchy, file, executable and device your chroot-ed program needs).

Listing 2 shows a recursive listing (ls -lR) of my example SafeFileEnvironment /var/mailjail.

Listing 2. Contents of /var/mailjail

Sendmail created the files /var/mailjail/var/spool/mqueue/bobo and .../root. Beforehand, I had created the entire chroot jail with only four commands:

mkdir -p /var/mailjail/var/spool/mail
/var/mailjail/var/spool/mqueue
cd /var/mailjail
chown -R mail:mail *
chmod -R 700 *

If you're concerned about unsolicited commercial e-mail, there's some good news. By default, sendmail doesn't allow SMTP relaying, a common technique of spammers. This can be disabled in sendmail.mc, but you won't find out how from me. Leave this alone. In addition, you can direct sendmail to reject mail from known sources of spam, per the Realtime Blackhole List (RBL), by adding or uncommenting this line:

FEATURE(`dnsbl')
For this to work, however, you need to subscribe to the RBL. See Resources for a link to its home page, where you'll find subscription and use instructions and some important disclaimers. (Note that while RBL subscriptions are free for “Individual/Hobby Sites”, there is a fee-schedule associated with this service.) Using the RBL can block e-mail from some legitimate users as well as from spammers, so proceed with caution.

If you run Red Hat 7.1 or 7.2, there's one more sendmail.mc parameter to check, this time one that needs to be commented out. If your /etc/mail/sendmail.mc contains a line like this:

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

Then you need to comment it out by appending the string dnl to the beginning of the line. If active, this line will cause sendmail to accept only connections on the loopback interface and not from external hosts. Needless to say, for an SMTP gateway this is undesirable (though it unquestionably enhances security).

Those are the most important sendmail.mc settings for our purposes. There are others relevant to security, especially for nongateway roles (local delivery, etc.). For more information see the README.cf or README file I alluded to at the beginning of this section.

To compile our macro-configuration file into sendmail.cf, we use this command:

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

If your macro-configuration file's name isn't sendmail.mc, substitute it with linux.mc or whatever your macro-configuration file is called. Sendmail expects its configuration file to be named sendmail.cf; however, it looks for it in /etc, so that part of the command is the same regardless of your distribution or even your version of sendmail.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

change /var/spool/mail

Luis Cuenca's picture

hi,
I need help abuot the configuration of the sendmail
what is the configuration to change the MAIL_DIR /var/spool/mail to other direcction?

sendmail Doubt

Dominic's picture

Hai,will sendmail work as SMTP server with out any authentication for
users those who are sitting remotely.i don't want put it as open rely.but only the @abc.com domain user can relay mail from both local and remote locations with out any authentication.Is it possible ?

Regards,
Dominic

Re: Paranoid Penguin: Hardening Sendmail

viking's picture

does sendmail support maildir.. using IMAP using old bsd format email load cpu usage high/.. i am using Postfix and Courier IMAP..

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Yes it does. It probably supports anything, you just have to tell Sendmail which filter it uses to make local deliveries. Especifically for maildirs you can use the maildrop delivery filter. Use Google to find out more about "maildrop".

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

This article is useless... What a waste of my time....

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Then don't read it... moron.

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Not to me, it really did help me

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Not useless in the least... you saved my newbie butt! I'm a complete newb with linux, but my company needed a simple mailserver (aside from our usual Novell boxes) to relay certain types of email (coming from specific servers) out the door. Linux and sendmail seemed to be the smart choice.

Your article helped me more than I can say. I've printing out and read pieces and parts of instructions from all overon how to deal with sendmail... and none of them explained it clearly enough (or in detail enough for a beginner) to get me started. Now that I understand the basics, I have plenty of experimenting I can do. Eventually I see us using a linux machine as a firewall for incoming email too.

I'm now in love with linux, and it's not in small part due to your article.

Thanks a ton,

Jason

Configuring Sendmail

Anonymous's picture

Check out Install-Sendmail which'll configure Sendmail. It's horribly easy to run and I'm going to look at some of the advice here for future improvements..

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

I wonder if it's a joke mistakingly posted two weeks in advance or if Bauer placed the wrong posting date by mistake. I am not kidding.

Cheers!

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

> Here is a simple access file:

> localhost.localdomain RELAY

> localhost RELAY

> 127.0.0.1 RELAY

You shouldn't use the entries above in your access db. They're useless as sendmail will work without it. On the other hand, most RBLs (e.g. ORDB) will detect your machine as open mail-relay and put it in their blackhole database. All entries above should be set to REJECT.

Regards

A. Danzer

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

This will only open your machine for relaying from localhost, although the top 2 lines are useless and can be exploited with some dns poisoning.

You shouldn't reject mail from 127.0.0.1 should you? Sounds stupid to me.

Baldur

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Setting these lines in the access.db doesn't block people from using the server to send junk to users on the local machine.

I'm looking for a solution to that problem if anyone is up for the chalange...

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

I have these lines in my sendmail access db; they've been there for years. I'm running the latest RedHat OEM'ed sendmail right now.

ORDB has just tested me for open relays and found nada, so there must be more to the problem than you think.

PS - my domain does both ingress and egress filtering, and those names are in the local DNS as well, so that may be why it works for me.

--The Rev

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Good overview article.

> ... sendmail must run as root if any portion of

> its required functionality does, i.e., writing

> mail to multiple users' home directories.

This isn't necessary. You can run sendmail as an ordinary user account and use group "mail" as the means to do the writing into /var/mail or other mail files.

The sendmail maintainers appear to have made a lot of progress in making sendmail's security more robust over the last several years.

Part of the reason its still so big as a whole is it can probably do more mail delivery tricks (processing, delivery means (TCP/IP, uucp, etc.), etc.) than other MTAs.

The default behavior since Sendmail 8.8 or so (as I recall) is to not relay mail.

If security is a real concern, you probably want an SMTP proxy host in front of your mail server. smtpd is a good solution. It acts as a store and forward mail gateway which strictly enforces the SMTP mail rules. You can also use tcp wrappers, and the MAPS Realtime Blackhole List with smtpd.

A well configured mail proxy on a secured system (OpenBSD or one of the security oriented linux distros make a great choice) talking to a mail host with a user mode chrooted sendmail for delivery will wear out most crackers before they compromise your mail server.

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Is there a free rbl site that has opened up in the wake of rbl requiring a contract with them (even for so-called free for individuals)?

robert

Re: Paranoid Penguin: Hardening Sendmail

Anonymous's picture

Sendmail does sanity checks on its environment at start up. A group writeable directory is considered to be a security issue, so sendmail will not start.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState