Sendmail Security

NEWS CONTENTS

• 191001 : Hardening Sendmail ( Hardening Sendmail, )
• 191001 : Configuring Delivery Rules ( )
• 191001 : MAPS - Support - Application Note How to secure your mail system against third-party relay ( MAPS - Support - Application Note How to secure your mail system against third-party relay, )
• 191001 : sendmail.net 000705securitygeneral ( sendmail.net 000705securitygeneral, )

Old News

Hardening Sendmail

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, [email protected] rather than [email protected], 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.

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 [email protected] 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.

Configuring Delivery Rules

That was the hard part. Now we only need to tell sendmail what to do with incoming mail, what local hostnames are legitimate and which users, networks and domains may use the SMTP gateway to relay mail not destined locally.

The mailertable is used to define delivery rules. It has a simple syntax, which is described in /usr/share/doc/sendmail/README.cf or /usr/share/sendmail/README depending on your distribution. In a nutshell, each line contains two parts: a destination identifier and an action. The destination identifier matches destination addresses or parts thereof; the action tells sendmail what to do with messages whose destinations match the identifier.

If the identifier begins with a ``.'', then all e-mail source addresses ending in whatever follows the dot will match. If it doesn't, then everything following the ``@'' sign must be identical to the identifier. The e-mail address [email protected] won't match the identifier polkatistas.org but will match .polkatistas.org.

The action takes the form agent:action where agent is either a mailer (defined in sendmail.mc/linux.mc in MAILER() statements) or the built-in agents ``local'' or ``error''. The ``local'' agent, of course, means the mail should be delivered to a local user, specified after the colon (if nothing follows the colon, the user specified in the message itself will be used).

Below is a mailertable with two different actions:

polkatistas.org       smtp:internalmail.polkatistas.org
mail.polkatistas.org  local:postmaster

In addition to delivery rules, sendmail needs to know which e-mail destinations should be considered synonyms of the local (SMTP gateway's) hostname. These are specified in /etc/mail/local-host-names, one per line:

mail.polkatistas.org
weird-al.polkatistas.org
1.23.234.2

Finally, we need to define allowed relayers by editing /etc/mail/access. The syntax is simple. Each line contains a source name or address, paired with an action (again, see README.cf or its equivalent on your distribution for details). The action can be RELAY, REJECT, DISCARD, OK or ERROR. In practice, the most useful of these actions is RELAY. Because by default relaying is rejected, REJECT and DISCARD are only useful when defining exceptions to explicit RELAY rules.

Here is a simple access file:

localhost.localdomain           RELAY
localhost                       RELAY
127.0.0.1                       RELAY
192.168                         RELAY

Do you notice the absence of real hostnames in the example above? In this example, the SMTP gateway performs only outbound relays; inbound mail must be addressed to a local e-mail address, and outbound relays must originate from hosts whose IP addresses begin with the octets 192.168 (obviously a noninternet-routable network). I like this technique (using IP addresses) because then I can prevent IP address spoofing with my firewall rules, but I can't prevent forged From: addresses in e-mail (however, your needs may be different of course):

access
local-host-names
mailertable

SMTP AUTH (in sendmail version 8.10 and later) adds authentication to SMTP transactions, e.g., to determine whether to permit relaying. This is especially useful when systems or users don't run their own MTA but need to send mail, i.e., need to relay outbound mail through a central gateway.

If you're running an SMTP server that relays mail from other domains, you probably want this feature, as it's an important defense against unsolicited commercial e-mail, the perpetrators of which rely heavily on SMTP relays.

There's just one more file that may need tweaking: aliases. This file contains a map of e-mail aliases to user names. Usually an SMTP gateway doesn't need a very granular alias database; to translate entire domains' (or virtual domains') e-mail addresses you're better off using the user database (which, sadly, I don't have space to cover). It's fairly self-explanatory, though, so edit it if you need to.

Now three of the four files we've just discussed, mailertable, access and aliases, actually can't be used by sendmail directly; they must first be converted to databases. The /etc/mail file contains a handy Makefile for this purpose. To use it simply change your working directory to /etc/mail and enter this command:

Make access.db mailertable.db

Note that this won't work for aliases, which has its own utility, newaliases. Run newaliases without any flags to convert your changed /etc/aliases file into a new /etc/aliases.db file automatically.

And that's it for now. There's much I haven't covered, notably the smrsh shell (applicable mainly to local mail delivery, not to gateways). But hopefully I've given you some useful hints and pointers to more complete sources of information. Good luck!

Resources

Mick Bauer ([email protected]) is a network security consultant in the Twin Cities area. He's been a Linux devotee since 1995 and an OpenBSD zealot since 1997, and enjoys getting these cutting-edge OSes to run on obsolete junk.

Re: Paranoid Penguin: Hardening Sendmail (Score: 0) by Anonymous on Friday, March 15, 2002

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 by Anonymous on Monday, March 18, 2002
  
• Re: Paranoid Penguin: Hardening Sendmail by Anonymous on Sunday, April 07, 2002
  

Re: Paranoid Penguin: Hardening Sendmail (Score: 0) by Anonymous on Friday, March 15, 2002

> 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 by Anonymous on Tuesday, April 02, 2002
  
• Re: Paranoid Penguin: Hardening Sendmail by Anonymous on Thursday, September 12, 2002
  
• Re: Paranoid Penguin: Hardening Sendmail by Anonymous on Thursday, October 17, 2002
  

Re: Paranoid Penguin: Hardening Sendmail (Score: 0) by Anonymous on Sunday, March 17, 2002

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!

Configuring Sendmail (Score: 0) by Anonymous on Monday, March 18, 2002

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 (Score: 0) by Anonymous on Friday, March 29, 2002

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

• Re: Paranoid Penguin: Hardening Sendmail by Anonymous on Wednesday, May 15, 2002
  
• Re: Paranoid Penguin: Hardening Sendmail by Anonymous on Tuesday, August 13, 2002
  

Re: Paranoid Penguin: Hardening Sendmail (Score: 1) by viking ([email protected]) on Tuesday, April 02, 2002 (User Info | Send a Message) http://jjsuthan.tripod.com/

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 by Anonymous on Wednesday, April 03, 2002

MAPS - Support - Application Note How to secure your mail system against third-party relay

Sendmail Version 8

    Status:  Freely Available
    Systems: Unix
    Info:    http://www.sendmail.org/

Versions before 8.8.4 require serious configuration hacking, and even then they aren't totally secure. Time to upgrade.

Rulesets for version 8.8.x are available from Claus AЯmann's web site at sendmail.org, http://www.sendmail.org/~ca/email/check.html. There are others around, but Claus's tend to be updated the most frequently.

Many sites which run 8.8.x have added anti-relay configuration, but are still susceptible to the "percent hack." Please pay special attention to the removelocal portion of check_rcpt in Claus's recipes to fix that.

Another approach is to limit mail server access to only those users who have authenticated themselves with a POP password, http://spam.abuse.net/adminhelp/smPbS.shtml. This is the so-called POP-before-SMTP solution. Although this is more complicated to setup, it is an excellent solution for providers that have "roaming users."

ISPs that are members of the iPass network should email [email protected] to obtain the "Anti-Spam Kit" for sendmail 8.8.

Starting with version 8.9.0, sendmail prohibits relay by default, and provides a number of parameters to control this feature. See the Anti-Spam Configuration Control section of the cf/README file for information on these settings.

Caution: Most of these solutions require you to setup a list of domains to which relay is allowed. Be sure to include all authorized domains in this list. Don't forget downstream domains for which you MX, as well as virtual domains that you serve. Otherwise you will begin rejecting mail that you shouldn't.

Another caution: if you have confiured sendmail 8.9.3 with FEATURE(relay_entire_domain), this will accept relays from any host in your domain. What's "your domain"? It's your host name with the first "word." stripped from it. Unfortunately, by default, sendmail checks *EVERY* IP address on your system and does reverse lookups.

Many systems have a default as-shipped 'localhost.rev' that has 127.0.0.1 point to localhost.berkeley.edu or something like this. This means that any host in berkeley.edu will be able to relay, but your own hosts may be rejected. There other services that rely on your server having correct reverse DNS as well, so it'd be a good idea to fix this.

Many, many, systems have at least one virtual host where the reverse DNS just points to the domain name, e.g., xxxstuds.com or some similar thing. This is where you end up with an open relay; such a machine will relay for anything in '.com'. Similarly, if you had a virtual host (or even just your main IP) resolving to 'example.net', you would discover that anything in '.net' was allowed to relay.

The best solution is to upgrade (including the .cf file); if for some reason you can't do that, specify relay hosts by IP address instead of using relay_entire_domain.

**** sendmail.net 000705securitygeneral -- Securing Sendmail

Though the virus alerts have vanished from the evening news, Internet security remains a justifiably hot topic. Still, while hype, myth, and hysteria abound, useful information seems to be in short supply. Had enough of generalities? Time for something, um, practical? We think so.

This two-part series on securing sendmail, based on the tutorial given by Eric Allman and Greg Shapiro at the recent USENIX technical conference in San Diego, begins by detailing the measures you can take to secure any sendmail installation. It continues tomorrow with a look at the specific roles sendmail can play - from timesharing systems to firewall installations - and how you can make those systems more secure. So dig in. Read on. And tell us what you think.

• What is security?
• General security principles
• Tuning sendmail for security
• Users special to sendmail
• General security measures
• File and directory modes
• Restrictive file access
• Controlling the aliases file
• smrsh
• The SafeFileEnvironment option
• More tricks for the truly paranoid

• Sendmail anti-relaying

• Stopping Spam with Sendmail

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Sendmail.org - Security Issues

• Sys Admin > v12, i06- Improving Sendmail Security by Turning It Off

• Quick fixes for Sendmail security ITworld

• sendmail Security Options

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019