|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|News||Recommended Links||Newsgroups||Recommended Papers||Reference||FAQs||RFCs|
|Sendmail hardening||Dual sendmail installation||Pipes in ~/.forward File||Email Forwarding||Spam filtering||Procmail||Humor||Etc|
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@example.com rather than firstname.lastname@example.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')dnlThe 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@example.com 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.netThe 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.cfIf 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 firstname.lastname@example.org 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:postmasterIn 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 22.214.171.124Finally, 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 RELAYDo 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.dbNote 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!
ResourcesMick Bauer (email@example.com) 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.
- 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.
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 (firstname.lastname@example.org) 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
Sendmail Version 8Status: 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@example.com 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.
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.
Google matched content
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
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019