Protecting Sendmail

   

---

After sendmail is installed and operational, your next step is customizing the configuration to suit your needs. The central sendmail config file is located at /etc/mail/sendmail.cf . Sendmail is unique in that you can edit either the main configuration file (as we did with the DontBlameSendmail option earlier), but more frequently you'll make your first changes to a macro file ( .mc ), which is then run through the m4 macro processor to generate the more complex /etc/mail/sendmail.cf file.

If this seems confusing, don't worryit is. The sendmail.cf file is extremely difficult to configure by hand. To counteract the complexity, sendmail has built macros (called "Features") that can generate many of the complex settings for you. You edit the macro-based configuration file, process it with m4 , and voila: The final sendmail.cf file is generated.

NOTE

You'll need to be logged in as root or use sudo to make changes and generate the sendmail configuration file.

Apple has included the basic Darwin (Mac OS X) sendmail macro configuration in the file /usr/share/sendmail/conf/cf/generic-darwin.mc . You should not make any changes to this file. Instead, create a copy ( sendmail.mc ) and use it to add your changes.

To begin, let's take a look at how to generate the basic configuration that came with your computer. You can follow these steps to reset sendmail to its "fresh-install" state:

1. First, copy the Darwin macro file someplace safe for editing: cp /usr/share/sendmail/conf/cf/generic-darwin.mc /tmp/sendmail.mc .

2. Next, run the m4 macro processor on the file: m4 /usr/share/sendmail/conf/m4/cf.m4 /tmp/sendmail.mc > /etc/mail/sendmail.cf .

3. The sendmail.cf is regenerated.

If you make any mistakes or find that sendmail is no longer starting, this is a quick way to get the system back to a state that you can deal with.

CAUTION

Each time you regenerate your sendmail.cf file, whether to add a configuration option or reset it to the default state, you must edit the file to add the DontBlameSendmail option discussed earlier, unless you chose to modify directory permissions in lieu of relaxing the sendmail security restrictions.

Now let's look at how you can protect your newly active server. As I mentioned earlier, you are not susceptible to many of the earlier attacks that plagued sendmail, so your primary focus should be on protecting the server from unauthorized use, such as relaying or being used to deliver SPAM to your users.

You're in luckpartially. The sendmail distribution that ships with Mac OS X is already configured to block relay requests . However, you still need to tell the server what it should allow . Setting the domains allowed for relaying is a matter of creating and editing the file /etc/mail/relay-domains .

The relay-domains file can contain individual hosts or domains for which your server will relay messages. For example, if I want my server to accept messages from the domains poisontooth.com , shadesofinsanity.com , and vujevich.com , I'd add each of these to the /etc/mail/relay-domains file:

 #  more /etc/mail/relay-domains  poisontooth.com shadesofinsanity.com vujevich.com 

You can also add individual hostnames or IP addresses to the relay-domains file if you prefer to restrict access to specific machines.

After making updates to your relay list, you must restart sendmail (by rebooting or sending a HUP signal with kill ) for the changes to take effect.

Sendmail Features

For the simple level of relay control we've seen so far, you won't need to generate a new sendmail.cf file. Many more relay "features" can fine tune the relay conditions for your server, and these will require you to edit your sendmail.mc file and regenerate sendmail.cf . Table 13.4 contains a list of available features and their use.

NOTE

To use any of the following features you should first create a copy of /usr/share/sendmail/conf/cf/generic-darwin.mc for editingsuch as /tmp/sendmail.mc .

All new features will then be added as new lines to /tmp/sendmail.mc , which will be used to generate /etc/mail/sendmail.cf when you type m4 /usr/share/sendmail/conf/m4/cf. m4 /tmp/sendmail.mc > /etc/mail/sendmail.cf .

Sendmail must be restarted after adding features.

Table 13.4. Sendmail Relay Features

Feature	Description
FEATURE('relay_hosts_only')	Matches only specific hosts in the relay-domains file, rather than domains.
FEATURE('relay_entire_domain')	Relays for your entire local domain.
FEATURE('access_db')	Uses a hash database /etc/mail/access for controlling relay options. We'll examine this in detail later in this chapter.
FEATURE('blacklist_recipients')	Uses the /etc/mail/access database for controlling mail recipients as well as senders.
FEATURE(' dnsbl ')	Enables real-time blacklisting service for incoming messages. We'll also look at this in detail shortly.
FEATURE('accept_unqualified_senders')	Loosens the restriction of having to have a domain name as part of a sender address. Allows simple usernames (such as "jray") to be used.
FEATURE('accept_unresolvable_domains')	Instructs sendmail to accept messages from domain names that cannot be resolved with DNS lookups. Not a good idea.
FEATURE('relay_based_on_MX')	Allows relaying for any domain that has an MX record that points to your mail server.
FEATURE('relay_local_from')	Relays messages that "appear" to come from your domain. Because this is easily spoofed, it doesn't provide very good protection.
FEATURE('promiscuous_relay')	Relays everything. A very very bad idea.
FEATURE(' smrsh ')	Limit users' program access from .forward files.

NOTE

For more information on sendmail relaying, read the official documentation at http://www.sendmail.org/tips/relaying.html.

Sendmail's Access Database

One of the more powerful relaying options is the sendmail access_db feature. This gives you control over the messages that move through your system down to the email address level. You can reject domains, hosts, and email addresses, all from a single location. Enable the access database by adding the following lines to your sendmail.mc file, generating the sendmail.cf file, and restarting sendmail:

 FEATURE('access_db') FEATURE('blacklist_recipients') 

The first of the two lines enables the access control database, whereas the second (optional) line allows entries into the database that will block outgoing messages to specific recipients.

The access database is built from a simple text file that consists of lines containing a hostname, domain, IP address, or email address and an action that should be taken when the element is matched. Table 13.5 shows the five available actions.

Table 13.5. Access Database Actions

Action	Result
OK	Accept mail regardless of any other rules or access control blocks.
RELAY	Accept email to or from the named domain.
REJECT	Reject email to or from the named address. An error message is returned to the client.
DISCARD	Silently reject email to or from the named address.
ERROR:<### Message>	Identical to REJECT , but allows a custom error message to be sent.

For example, consider the following access database file ( /etc/mail/access.txt ):

 [e-mail]     ERROR: "500 You won't spam us again." evilandgood.com                ERROR: "500 Your domain is a known spam source." nicepeople.evilandgood.com     OK poisontooth.com                RELAY 10.0.1.250                     RELAY 

• Line 1 . Mail to or from [e-mail] is rejected.

• Line 2 . Sets up the same rejection behavior for any messages coming from the evilandgood.com domain.

• Line 3 . Overrides the line 2 rejection for the host nicepeople.evilandgood.com .

• Line 4 . Relay messages to/from poisontooth.com .

• Line 5 . Relay messages from the host 10.0.1.250.

Set up your own rules in a temporary text file, such as /etc/mail/access.txt . This file will then be processed with the makemap hash command to generate the binary hash file that sendmail uses internally:

 # makemap hash /etc/mail/access < /etc/mail/access.txt 

The access database should be owned by root and writable only by root. As with most everything, you need to restart sendmail after updating the access database.

Real-Time Blacklisting

Another useful feature of sendmail is the ability to use real-time DNS blacklisting ( RBL ) services to block messages from known spam and open-relay sources. After blacklisting is enabled, each incoming connection is checked against a dynamic online database (on mail-abuse.org) to determine whether it is from a known open relay or spammer. If a match is found, the message is rejected. The list of relays and spam sources is kept up to date by user submissions, so it is always growing and evolving.

To activate this feature for your server, add the line

 FEATURE('dnsbl') 

to your sendmail.mc file, then use m4 to regenerate the main configuration file, as discussed earlier.

To test for blacklisted addresses, a standard DNS lookup is performed on a specially constructed version of a hostname. For example, if you want to check the IP address 140.254.85.225 to see whether it is blacklisted, you would look up the special address 225.85.254.140.blackholes.mail-abuse.org . As you can probably tell, this is nothing but the IP address reversed with .blackholes.mail-abuse.org added to the end. If a lookup on the address fails , it is not blacklisted:

  %nslookup  Default Server:  carrot3.poisontooth.com Address:  10.0.1.250 >  225.85.254.140.blackholes.mail-abuse.org  Server:  carrot3.poisontooth.com Address:  10.0.1.250 *** carrot3.poisontooth.com can't find 225.85.254.140.blackholes.mail-abuse.org 

To see an example of a "successful" (or blacklisted) lookup, use the IP address 127.0.0.2or 2.0.0.127.blackholes.mail-abuse.org . This address, reserved for testing, should show return a valid DNS lookup:

  %nslookup  Default Server:  carrot3.poisontooth.com Address:  10.0.1.250 >  2.0.0.127.blackholes.mail-abuse.org  Server:  carrot3.poisontooth.com Address:  10.0.1.250 Name:    2.0.0.127.blackholes.mail-abuse.org Server:  carrot3.poisontooth.com Address:  127.0.0.2 

For more information on the RBL system, visit http://mail-abuse.org/rbl/usage.html. Unfortunately, commercial licenses to the mail-abuse.org service do cost money. Noncommercial use is free, but you must register your mail server with mail-abuse.org before you can successfully query the DNS.

Other RBL services are available that you can use at no charge if you don't want to use the built-in mail-abuse.org settings. To use an alternative RBL server, simply specify a second parameter to the features, such as:

 FEATURE('dnsbl','spamguard.leadmon.net') 

Searching for RBL or RBL DNS is the easiest way to find the "latest and greatest" blacklisting servers that are currently active. Here are a few to try for starters:

• relays.osirusoft.com

• spamguard.leadmon.net

• spam.dnsrbl.net

• korea.services.net

• sbl.spamhaus.org

• spamsites.relays.osirusoft.com

Restricted Shell

If you're running an "open" system with user shell accounts, you should consider restricting what they can do with their .forward files, which can be created inside a user's home directory. The .forward file is typically used to forward messages to another account, or invoke another program, providing incoming email contents as standard input. These files should nominally be set to mode 600 ; looser restrictions cause sendmail to ignore them.

The .forward file consists of a line of destinations, separated by commas. While usually the file contains a single external email address for forwarding (such as [e-mail]), the destinations can be local accounts, email addresses, files, or piped utilities. An example for my account ( jray ), might look like this:

 \jray, " /usr/bin/vacation jray" 

In this example, the first destination, \jray , causes a copy of the incoming message to be delivered to my local account. The \ indicates that this is an end address and no aliasing should take place (to help eliminate the chance of infinite mail loops ). The second destination " /usr/bin/vacation jray" pipes the incoming message to the vacation utility with the command-line parameter jray . Commands (in this case, vacation ) are executed SUID the owner of the .forward files.

The trouble with .forward is that it provides a means for a user to execute a potentially untrusted program with arbitrary input. Even though the sendmail application may be secure, the called application may include a vulnerability that could be inadvertently (or intentionally) be exploited.

To limit what a user can execute, you should consider adding FEATURE(smrsh) to your sendmail.mc file and regenerating the .cf file. This feature activates the Sendmail Restricted Shell which limits what can be executed through the .forward file or aliases file to the programs contained, or linked, within the directory /usr/adm/sm.bin . The smrsh utility even rejects potentially dangerous characters such as redirects if they are included in the string to execute.

For example, if you wanted to provide users access to vacation and only vacation , you could do the following as root:

 # mkdir -p /usr/adm/sm.bin # chmod 600 /usr/adm/sm.bin # ln -s /usr/bin/vacation /usr/adm/sm.bin/vacation 

The first two lines create and set permissions for the /usr/adm/sm.bin directory. (The directory should be owned by root and writable only by root.) The third line creates a symbolic link from /usr/bin/vacation to /usr/adm/sm.bin/vacation , allowing it to be executed from .forward or your aliases file.

You should never link a shell or interpreter such as Perl into the sm.bin directory. This provides an open (and inviting ) door for intrusion.

TIP

Even if you aren't using .forward files, you may still want to use the smrsh feature, because it provides the same restrictions for your aliases database. Although your aliases file should be writable only by root, if it were compromised, only the /usr/adm/sm.bin utilities could be invoked through it.

Sendmail Options

Now that you've tasted the feature macros that you can add to your sendmail.mc file, let's take a look at configuration options that can be added directly to /etc/mail/sendmail.cf . Unlike the macro-based features, you don't need to regenerate the configuration file each time you add an option. However, keep in mind that if you edit your .mc file later and regenerate sendmail.cf , you'll need to add the options to the file again. Table 13.6 contains a number of options for additional access and security control. Options are added, one to a line, preceded by O :

 O <Option Name>=<Option Value> 

Table 13.6. Sendmail Options

Option	Description
AliasFile = <alias path and filename>	Sets a location for the sendmail alias file. Mac OS X defaults to the Netinfo /aliases directory, rather than a local file.
AllowBogusHELO	No value needed. If specified, this option will allow non-RFC 1123 HELO/EHLO values to be sent.
ConnectionRateThrottle = <incoming connection limit>	Applies a limit to the number of incoming connections within a one-second time period.
MaxDaemonChildren = <child limit>	Sets a limit to the number of child processes that can be running simultaneously .
MaxMessageSize = <message size limit>	Sets an upper limit, in bytes, for incoming messages.
MinFreeBlocks = <free filesystem blocks>	Refuses to queue messages if the file system free space (in blocks) drops below this limit. Use du to display the free space on your mounted volumes .
PrivacyOptions = <option1, option2, ...>	Sets how sendmail adheres to the SMTP protocol. Options include public , needmailhelo , needexpnhelo , noexpn , needvrfyhelo , novrfy , restrictmailq , restrictqrun , noreceipts , goaway , and authwarnings , and will be discussed shortly.
QueueDirectory = <directory>	Directory to use as the mail queue.
QueueLA = <load average>	Sets the load average at which messages will be accepted, but sendmail will no longer try to deliver them.
RecipientFactor = <factor>	This number is added to the message priority (higher numbers are lower priority) for each recipient of the message. The more recipients, the lower the priority. Defaults to 30000.
RefuseLA = <load average>	Limits incoming connections based on the server's load average. Use uptime to view your computer's load averages.
RetryFactor = <factor>	Priority factor added to each message as it is processed and reprocessed. Defaults to 90000.
SafeFileEnvironment = <directory path>	Limits sendmail's capability to deliver to anything but standard files in a specific location. Sendmail aliases and users with .forward files are forced to write any files to this directory.
StatusFile = <file path>	Path and filename of a file that is to store mail server statistics. This is a fixed-size log, and can be viewed at any time with mailstats .
UnsafeGroupWrites	When active, "include" files (as are often used in the alias file), and .forward files are considered "unsafe" and may not be used to write files or reference other programs.

Privacy Options

The PrivacyOptions option controls how strictly your sendmail server follows the SMTP protocol by enabling/disabling features in the SMTP protocol. For example, removing support for some functions ( EXPN , VRFY ) is a wise idea. It prevents remote attackers from verifying that an account name exists, or expanding an alias list to show the destinations. To use these two privacy options in the /etc/mail/sendmail.cf file, one would add the following line:

 O PrivacyOptions=noexpn,novrfy 

The complete list of privacy options is shown in Table 13.7.

Table 13.7. Available Privacy Options

Privacy Options	Description
public	Open access, no restrictions.
needmailhelo	Requires that the HELO/EHLO command be sent before MAIL .
needexpnhelo	Requires that the HELO/EHLO command be sent before EXPN .
noexpn	Disables the EXPN command entirely. This prevents alias lists from being expanded.
needvrfyhelo	Requires that the HELO/EHLO command be sent before VRFY .
novrfy	Disables the VRFY command, eliminating the opportunity for a remote user to verify that an account exists.
restrictmailq	Restricts the mailq queue-listing command to the owner or group of /var/spool/mqueue (root).
restrictqrun	Restricts the queue runs to the owner of /var/spool/mqueue (root).
noreceipts	Disables return receipt acknowledgement .
goaway	Activates all privacy options except for restrictmailq and restrictqrun .
authwarnings	Adds X-Authentication-Warning headers to messages.

NOTE

By default, Mac OS X comes with the authwarnings option set. If you are customizing the base configuration file, you should either comment out the existing PrivacyOptions line and add your own, or add your options to the existing line.

Safe File Environment

Users and administrators can employ the .forward and aliases files to perform a number of tasks , including forwarding messages to other accounts, piping them to other utilities, and writing to filessuch as mail archives. By allowing files to be created anywhere on the file system, sendmail opens itself to being capable of overwriting existing files, directories, and /dev device files. The SafeFileEnvironment option creates a chroot environment where files can be written and does not allow access outside the directory. By living with the inconvenience of only being able to write to a specific directory you can effectively shut sendmail off from being able to write to the rest of your system.

The SafeFileEnvironment is specified as an option and a directory, such as /archive :

 O SafeFileEnvironment = /archive 

You must, of course, also create the directory that sendmail is using as its Safe File Environment. You should also modify .forward files and the aliases database to use the correct path for any files they may write.

NOTE

In many cases, you may not need to update your alias/forward file paths (although it's still a good idea), because sendmail sets the base of any files being written to that of the SafeFileEnvironment . For an installation with /archive set, the two paths /archive/mailinglists/logs and /mailinglists/logs will be equivalent; both will write files to /archive/mailinglists/logs .

Aliases and Common Sense

A topic mentioned repeatedly throughout the sendmail configuration features and options is the aliases database. An alias is similar to a .forward file in functionality, except it applies to the entire mail server, not just a single account.

Aliases are more of an operational issue than one of security, so we've saved them until last. By default, Mac OS X stores sendmail aliases in the Netinfo /aliases directory, accessible through the NetInfo Manager or the nicl command-line utility. Although convenient from the Mac-user perspective, most sendmail installations on other systems use the file /etc/mail/aliases to store alias information. This file is easier to edit and more convenient for maintenance than the NetInfo directory. To activate the /etc/mail/aliases file on your system, edit /etc/mail/sendmail.cf , looking for the following line:

 #O AliasFile=/etc/mail/aliases 

Uncomment the line, so that it reads as follows:

 O AliasFile=/etc/mail/aliases 

Then save the configuration file. After restarting sendmail, you can start using /etc/mail/aliases for storing aliases. This file should be owned and writable by root. Opening it to editing by anyone else means risking your system's security. The aliases file itself contains the raw data defining account aliasesit is not the file that sendmail uses directly. The actual aliases database is stored in /etc/mail/aliases.db and you create it by running the newaliases command as root each time you make changes to the raw data in /etc/mail/aliases .

So, what does the alias database do, and how does it relate to security? As mentioned earlier, the alias database is similar to a .forward file. It takes incoming messages and directs them to a specific account mailbox, email address, utility, or file. As such, it has the same security risks as a .forward file, but encompasses the entire system, rather than a specific user account. By default, Mac OS X includes the following aliases in NetInfo:

administrator	root
dumper	root
MAILER-AGENT	postmaster
MAILER-DAEMON	postmaster
manager	root
nobody	root
postmaster	root

The alias (administrator, MAILER-AGENT, and so on) is paired with a destinationin the case of the default aliases, either root or postmaster. Because postmaster itself is aliased to root, the destination of all the aliases is the root account mailbox.

Within the NetInfo naming conventions the aliases are the Netinfo directory "names," and the aliases are the " members ", as shown in Figure 13.1.

Figure 13.1. NetInfo stores the sendmail aliases in the /aliases directory.

The aliases file follows a similar structure of alias names and destination members: separated by a colon ( : ), one alias definition per line:

 <alias name>:    <destination,destination,...> 

The Netinfo aliases can be rewritten to a standard /etc/mail/aliases file like this:

 administrator:        root dumper:            root MAILER-AGENT:        postmaster MAILER-DAEMON:        postmaster manager:        root nobody:            root postmaster:        root 

Besides just aliasing a single name to an account (or another alias), you can also add multiple destinations to a given alias name, and these destinations don't have to be accounts. Alias destinations can be any of the following:

• Full qualified email addresses . Besides just local accounts, you can use full email addresses, such as myaccount @anotheraddress.com , to forward the mail to another server.

• File Names . A file in which to store the contents of the incoming message, useful for archiving incoming messages.

• Included Destinations . For creating a simple mailing list that works by redirecting incoming messages to a list of recipients, you can add a special "include" destination by prefixing a fully qualified path to the list of destinations (usually just a list of email addresses) with the text :include: . For example, to include a list of email addresses in the file /etc/mail/mylittlelist as destinations, I'd use :include:/etc/mail/mylittlelist as one of the destinations for my alias.

• Programs . Like a .forward file, an alias can also use a program as a destination. This is often used for "auto-responders" that deliver help or other information when a message is sent to a given email address.

Because of the capabilities of the aliases file (and Netinfo /aliases ), you should always make sure you know exactly what is contained in your system aliases. Often people inherit mail servers with extremely complex alias definitions, some of which may be security risks. Keep in mind that the SafeFileEnvironment option and smrsh feature both affect the aliases database, so activating these options will help protect your aliases from being used for something nefarious.

---

Top