4.2 SendmailAlmost every Linux shop runs Sendmail and allows any system in the world to connect to it. It needs root access to open its privileged port (TCP port 25) and to enable all its features. Next to the kernel, and possibly X, Sendmail may be the most complex component of Linux and you could spend a lifetime learning about it. It will be assumed that your systems have been upgraded to Sendmail 8.10 or higher and that you have applied the suggestions that were discussed in "Upgrade sendmail" on page 107 and "Fortify sendmail to Resist DoS Attacks" on page 109. We will proceed from there.
If your version of Sendmail is older than 8.9.3, there are known buffer overflow exploits and spam relay exploits that you are vulnerable to, so you will want to upgrade immediately. See "Upgrade sendmail" on page 107 for the details on upgrading Sendmail. A variety of problems and solutions related to Sendmail will be discussed here. There are other freeware alternatives to Sendmail, such as postfix and qmail. Many people consider these to be easier to use and more secure than Sendmail. Now that Eric Allman, Sendmail's creator, has founded the well-capitalized Sendmail, Inc., there have been good support and new features for Sendmail. The postfix program is recommended by many security experts as a more secure mailer than Sendmail. It was developed by Wietse Venema, one of the most regarded Linux developers, at IBM's TJ Watson Research Laboratory, one of the world's best research labs.
The postfix program was designed from the ground up with security in mind and using the "Rings of Security" model to minimize single points of security failure. One of the techniques employed is the use of separate cooperating processes to interact with the Internet, to receive locally originated mail, and to deliver mail locally. The processes interacting with the Internet do not have the authority to do anything harmful. Only one of the processes that comprise postfix, the master, operates as root and it does not interact with the Internet; all the postfix programs may be chrooted. By having separate processes in this way, in order to break into a system, a cracker has to break several processes rather than just one, which is much harder. This is different from Sendmail, which operates a single root process so that if any one line of code that can be executed has a security hole, the program is compromised. (In Appendix A, a URL is supplied where it is explained how to configure Sendmail to not run as root.) The postfix program may be downloaded from one of the mirrors linked from www.postfix.org/ 4.2.1 Separate or Multiple Mail Servers for Additional SecurityIt is hoped that recent versions of Sendmail are secure. I am not aware of any reports of vulnerabilities in Sendmail 8.10, assuming that it has been configured properly. It offers some automatic checks for certain common errors in configuration that can compromise security. Because of past security problems, many sites choose to dedicate a separate system in the DMZ to handle only mail. Thus, if a vulnerability is found, there is much less that can be damaged. This damage is limited because the only thing of value on this system is e-mail in the spool directory. This would be e-mail that is awaiting download via POP or IMAP. If it is confidential, it should be encrypted with PGP anyway. Some sites will go a step further, and have two mail servers one externally visible in the DMZ (the external mail server or Xmail), and one inside the main firewall (the internal mail server or Imail). Mail coming in from the Internet goes to Xmail which then sends it to Imail. Imail then makes it available to users, possibly via POP or IMAP. The Xmail server could intensely filter out spam, as discussed in "Blocking Spam" on page 185. E-mail generated internally that is destined for the Internet goes to Imail, which then sends it to Xmail. Xmail sends it on its way. The firewall rules between the DMZ and internal network would block all port 25 traffic and all traffic from or to Xmail, except that it allows traffic to port 25 of Imail from Xmail and to port 25 of Xmail from Imail. This configuration prevents external sites from directly attacking any systems inside the firewall. Internal e-mail does not leave the firewall-protected internal environment. Two systems (Xmail and Imail) must be compromised, one through a firewall, before a cracker can even start an attack on a nonexpendable internal system. 4.2.2 Basic Sendmail SecurityKeep in mind that normally sendmail runs as root, and accesses a great many different files. Those that are configuration files (and all directories leading to them) must have the correct permissions and ownership for proper security. For example, if /etc/sendmail.cf is writable by all, there is no security. In Red Hat 7.3, sendmail.cf is in /etc, sendmail is in /usr/sbin, and the mqueue directory is in /var/spool. These may be different in other distributions. The sendmail program, sendmail.cf, and /var/spool/mqueue should all be owned by root and only the owner should have write permission. There is no reason for any of them to be readable by other than the owner, root, though this should not make much of a security difference. The sendmail program must be set-UID to root in a normal installation, where it runs as a daemon.
The other configuration files that Sendmail uses (and their directories) must not be world writable. This is particularly true for aliases aliases.db mailertable mailertable.db The alias capability allows the SysAdmin to arrange for e-mail sent to certain addresses to be sent to any program as standard input. This is a wonderful and powerful feature that has many uses. It can be used to cause almost any event to happen, such as generating mailing list digests, operating X10 devices,[1] and updating the /etc/hosts files of neighboring systems when a system with dynamically changing IP address suffers a change.
Because the invoked program runs as root, using this feature creates security holes unless the program is written very carefully. The problems are very similar to those of CGI programs, except that CGI programs normally do not run as root. Verify that your Sendmail version does not support the debug, wiz, or kill commands. This may be tested by connecting to your Sendmail and issuing these commands thusly. telnet mail.pentacorp.com smtp 220-mail.pentacorp.com Sendmail 8.9.3/8.8.7 ready at 6 Sep 2000 22:20 220 ESMTP spoken here wiz 500 Command unrecognized debug 500 Command unrecognized kill 500 Command unrecognized quit 221 mail.pentacorp.com closing connection Connection closed by foreign host. In this example, the Sendmail tested does not support these insecure commands, so it is safe from these threats. If you get any response other than 500 Command unrecognized, you need to upgrade your version of Sendmail. For older Sendmail installations, search the /etc/sendmail.cf file for a line starting OW The "O" command is enabling the "W" option. If the "W" option is enabled, the wizard's password will be accepted; many crackers know what it is. The following command will do this: grep '^OW' /etc/sendmail.cf This would be the wizard's password. If it does not look like the following line, then it should be changed to look like it. This will disable the wizard's password. Failure to do so will offer a shell to anyone who knows the wizard's password. OW* Inspect the /etc/aliases file and analyze any alias that outputs to a program or file instead of a mailbox. Remove the decode alias, if present, because it opens up a vulnerability; it will look like decode: "|/usr/bin/uudecode" Even better than removing the decode alias, send its e-mail to root to alert yourself to possible attacks with the entry decode: root E-mail can accumulate in the mailbox of any account in /etc/passwd. Some of these accounts are not for human use. E-mail sent to these accounts should be rerouted to accounts whose mailboxes are read by a SysAdmin (or thrown away) to avoid megabytes being accumulated over time. Be sure to offer abuse, Postmaster, and MAILER-DAEMON mailboxes since all these are expected by net etiquette. Many sites also offer sales and support. The following would be typical. root: sysadm sales: jtfasttalker support: nopatience sysadm: spock abuse: root Postmaster: root MAILER-DAEMON: Postmaster bin: root daemon: root adm: root lp: root sync: root shutdown: root halt: root mail: root news: root uucp: root operator: root games: root gopher: root ftp: root nobody: root xfs: root gdm: root After any changes to the /etc/aliases file, issue the command newaliases to compile the /etc/aliases file into the /etc/aliases.db database that Sendmail actually uses. The newaliases command will not be necessary if the line O AutoRebuildAliases is present in the /etc/sendmail.mc file. In this case, the line Oa5 will cause the /etc/aliases file to be compiled into /etc/aliases.db within five minutes of its being changed. (Older versions of Sendmail used ODTrue instead.) 4.2.3 Sendmail Security OptionsRecent versions of Sendmail have a number of security options that most sites will want to use. First, the options and their effects will be discussed. Then, how to enable them will be explained. Setting the "authwarnings" privacy option will cause sendmail to issue a warning if it detects certain insecure features in the configuration. Sendmail offers the VRFY (verify) command that any Internet site may use to ask your Sendmail if a given name is a valid e-mail address. Spammers use this to guess e-mail addresses. They will try joe, dan, sally, smith, and so on, noting those that are valid, for later spamming. A cracker can use this technique to determine account names to then start guessing passwords on, making his job much easier. Because Sendmail does not need to fork any processes, lock any mailboxes, or do anything else that is time-consuming, this is a very efficient and quick operation for the spammer. You will want to remove the efficiency so that the spammer cannot harvest as many e-mail addresses.
Almost all sites should disable the VRFY command. This is done with the "novrfy" privacy option. The EXPN command is similar to the VRFY command in that EXPN will expand (reveal) the actual delivery addresses of mail aliases and mailing lists. This will allow the collection of more e-mail addresses in case you later decide to block access to the alias from the Internet. For example, to see what the all mailing list expands to, assuming it exists, issue the following request to sendmail: EXPN all This EXPN is disabled with the "noexpn" privacy option. Similarly, the "restrictmailq" privacy option should be specified to prevent Sendmail from telling anyone who asks what is in the mail queue. It will let only those in the same group as the mail queue directory see this data. The "needmailhelo" privacy option will require the client system to identify itself with a HELO command before mail will be accepted from it. The HELO command will cause the sending system's host name and numeric IP address to be logged via syslog. If the sending system is running ident (the auth service), the user name or UID will also be logged. Thus any shenanigans can be traced back to the perpetrator. If the perpetrator owns the sending system, he can send fake ident data, of course. By default, Sendmail will not enforce a limit on the number of children that the daemon will fork, when listening on port 25. This allows a DoS attack by sending so many messages to your system in a short period of time that the process table or the number of open file descriptors is saturated. Certainly, an attacker can start one TCP connection to port 25, have the initiating program sleep, start a second TCP connection to port 25 to spawn a second child, and repeat. An attacker could use multiple compromised systems. The antidote to this DoS is to add the confMAX_DAEMON_CHILDREN define to /etc/sendmail.mc, specifying the maximum number of children you will allow at one time. This will add the O MaxDaemonChildren=25 line to the generated sendmail.cf file. See Table 4.1. The sendmail program shares a problem with several other parts of Linux, including named, ftpd, and the typical telnetd configuration file. This problem is that sendmail happily tells any computer that asks what its version number is. This makes it easier for crackers to know which vulnerabilities to apply. Again, back around 1980 it was a good idea to help debug compatibility problems between systems. Today it is a poor idea. It allows crackers to catalog the world's active sendmail processes, and wait for new vulnerabilities to be discovered in particular versions. Then, they instantly know which systems they can break into. The solution is another "one-liner." Change the greeting message to not include the "$v" macro that tells Sendmail's version or the "$Z" macro that reveals the sendmail.cf version. The latter is a strong hint as to what range of versions the sendmail program could be. A text editor may be used to remove the strings $v and $Z from the /etc/sendmail.mc file. To enable all these security features, which is suggested, ensure that /etc/sendmail.mc includes all the entries in Table 4.1.
After editing /etc/sendmail.mc, issue the following shell commands to have your changes take effect. m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart Note that m4 is the Linux and UNIX general macro processor. The /etc/sendmail.mc file includes the main definition file, /usr/lib/sendmail-cf/m4/proto.m4. The most commonly altered items are listed in /etc/sendmail.mc; this is to free most SysAdmins from learning the challenging details of the sendmail.cf file. It is important to note that /etc/sendmail.cf now is generated by the m4 command shown above; it no longer is edited directly. Instead, to alter items not listed in /etc/sendmail.mc, editing /usr/lib/sendmail-cf/m4/proto.m4 is necessary. To check that your changes worked and that VRFY and EXPN have been disabled, use telnet to connect to port 25 (smtp) and issue these commands to verify that sendmail refuses to honor and obey them. telnet mail.pentacorp.com smtp 220-mail.pentacorp.com Sendmail Secure/Rabid; 6 Sep 2000 22:25 220 ESMTP spoken here VRFY foobar 252 Cannot VRFY user; try RCPT to attempt delivery (or try finger) EXPN foobar 502 Sorry, we do not allow this operation quit 221 mail.pentacorp.com closing connection Connection closed by foreign host. Sendmail documentation suggests using finger but you disabled it too, of course, as discussed in "Do Not Get the Finger" on page 94. Unfortunately, the attacker can still deprive others of being able to send e-mail to the system on a timely basis. There is not a good solution to this problem. Certainly, the ports program or netstat will indicate if this is a problem because they will show lots of connections to your port 25 from a particular system. Once such a problem is discovered, a firewall rule to block traffic from the offending system will solve the problem within seconds. One possibility for protecting against this problem automatically, suitable only for the brave, is to modify the sendmail source code, where it keeps track of how many children still are running. In the table where it keeps track of running children, add a field to store the IP address (or host name) of the system that it is connected to. When a new connection is received, search that table and count the number of pending connections with that IP address. If it exceeds some value, perhaps half of the allowed number of connections (MaxDaemonChildren), close the port and treat it like an error. An appropriate error would be the same one that would occur if MaxDaemonChildren would be exceeded. If it was a legitimate connection, the client system will try again later. Stateful firewalls that are sufficiently smart will handle this problem too. Online documentation to assist with configuring Sendmail may be found at www.redhat.com/support/docs/howto/RH-sendmail-HOWTO/book1.html www.sendmail.com www.sendmail.net www.sendmail.org 4.2.4 Forging Mail and News Sender's AddressThe sender's address that appears on received e-mail or on a Usenet News (Network News) post is generated by the sender's system. Similarly to the security deficiencies in NFS, this method of data transmission dates back to more than 30 years ago when only trusted researchers on U.S. Department of Defense sponsored sites were on what later would become the Internet. Forging a mail message's sender name does not even require root access because the unprivileged mail program that is the front end to sendmail generates these. Heck, one does not even need sendmail. Using telnet and specifying a destination port of 25 (SMTP) instead of the default port 23 one can inject bogus mail directly into the recipient's system. Sendmail will generate a may be forged error when an untrusted user claims to be someone else. A demonstration of mail forging is presented in "Mail Spoofing" on page 253.
4.2.5 Where Is All That Spam Coming From?It seems like every fool looking for a get-rich-quick scheme has discovered spam. Spam is to e-mail what junk mail is to paper mail. Simply, it is e-mail sent to people with no association with the sender. The vast majority of recipients have absolutely no desire to receive the mail. Their companies and ISPs certainly do not want their resources wasted on it.
Spammers get their lists of e-mail addresses of people to annoy in a variety of ways. The following are some of the ways:
Some ways to reduce spam are listed here:
4.2.6 Drop-Shipping Spam (Relaying Spam)Prior to Sendmail 8.9, any Sendmail program would happily accept e-mail from any system in the world and forward it to any other system in the world. This was great for spammers. They could send a single piece of e-mail to your system with 100 recipients on other systems and let your system use up its bandwidth and computrons sending out 100 e-mail messages. Further, because they would give a phony return address you would be blamed as the originator of the spam. Fortunately, as of 8.9, Sendmail will only accept e-mail where either the recipient or sender is within their domain unless relaying is enabled. Additionally, as of 8.9, Sendmail normally will not accept e-mail if the From: address has a domain that is not real. Unfortunately, Sendmail is not smart enough to verify that the claimed From: address matches the numeric IP that is connecting to sendmail. 4.2.7 Blocking SpamThere is the Realtime Blackhole List that is run by the MAPS project at http://maps.vix.com/. They accept reports of spammers and add them to the list. It is hard to get off the list. Both the actual spammers and any site that spam is relayed through (due to sloppy configuration by the SysAdmin) is a good candidate for this list. Add the line FEATURE('rbl') to the /etc/sendmail.mc file to enable the Realtime Blackhole List. Then cause this feature to take effect with the following shell commands: m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart By configuring your sendmail to query this site as to whether each piece of e-mail is spam, you will greatly reduce spam. 4.2.8 Spoofing Spam RobotsSpammers are not content just to get e-mail addresses from mailing lists and News groups. Some also search everyone's Web pages looking for addresses. Those "@" characters give it away, as does mailto: in the document. Some sites have taken to using dynamic pages to create an infinite number of generated links with bogus e-mail addresses. This wastes the spammer's cycles and bandwidth, both on getting these bogus pages and on sending e-mail to fake addresses. I do not have more details on how to do this but I am sure you can figure out basic techniques. One such program for generating these pages with fake e-mail addresses is called wpoison. It is available from www.novia.net/~doumakes/abuse/ This site has other anti-spam ideas including various filters. I do hope that if anyone does this, they make the effort not to confuse "good" search engines such as altavista.com and google.com. The "good" search engines will respect your asking them to avoid certain pages (such as the spam 'bot spoofing pages). Please do refer to "Robot Exclusion of Web Pages" on page 287 for the details on how to do this. 4.2.9 llowing Controlled RelayingThere are several features to enable some relaying without opening up your mail server to spam attacks. To enable relaying from all hosts within your domain, add the following to /etc/sendmail.mc: FEATURE('relay_entire_domain') Then cause this feature to take effect with the following shell commands: m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart The /etc/mail/access file may be used to reject e-mail from specified sites and to allow mail from sites that otherwise would be rejected. After editing this file, issue the following commands to cause the changes to take effect: makemap hash /etc/mail/access < /etc/mail/access/ etc/rc.d/init.d/sendmail restart Each line of /etc/mail/access is an entry. The first field of each line is an address that you want to work with. It may be an e-mail address, a domain, a fully qualified host name, or part of an IP address. This field should be separated from the next with one or more spaces or tabs. The next field should be an instruction telling sendmail what to do with e-mail from this address. Valid values are listed in Table 4.2.
As an example, say you want to reject e-mail from quickmoney@hotmail.com, anyone in the cracker.com domain, or in the 10.1.*.* network. You want to say Spammer, go home to anyone at stocktips.com, but you will accept e-mail from friend.stocktips.com. Because you see spam from eternal_youth@ from a variety of hostnames, you want to reject it too. And you want to relay for pentacorp.com. The following entries in /etc/mail/access would be needed: quickmoney@hotmail.com REJECT cracker.com REJECT 10.1 REJECT friend.stocktips.com OK stocktips.com 550 Spammer, go home eternal_youth@ 550 Spammer, go home pentacorp.com RELAY Note that the difference between OK and RELAY is that OK allows that site to send mail into your sites but RELAY also allows e-mail from that address to be sent back out onto the Internet (relayed). You also can blacklist recipients by adding the following line to /etc/sendmail.mc: FEATURE('blacklist_recipients') You then will need to issue the following commands to enable this: m4 /etc/sendmail.mc > /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart Once the blacklist_recipients feature is enabled, recipients may be blacklisted. To reject e-mail addressed to account george, demo.pentacorp.com, and sal@lab.pentacorp.com, the following lines in /etc/mail/access will work. george 550 George is on safari until February demo.pentacorp.com 550 It is a demo system, get a life sal@lab.pentacorp.com 550 We fired her After changing /etc/mail/access, be sure to restart Sendmail thusly: /etc/rc.d/init.d/sendmail restart 4.2.10 Allowing POP and IMAP Clients to Send MailDynamic relay authorization control (DRAC) interfaces with your POP or IMAP server to temporarily allow Simple Mail Transfer Protocol (SMTP) relay access from client systems that have picked up mail from your network recently, typically in the past 30 minutes. This is reasonably secure because both POP and IMAP require an account and password. The "reasonably" is because only the SSL-wrapped versions of these (SPOP and SIMAP) encrypt the password before sending over the Internet. If one of the SSL-wrapped versions of mail download clients used (SPOP or SIMAP), then this arrangement would have good security as there is but a small window of opportunity for someone else (e.g., whoever might get the dynamic IP address within 30 minutes of a client system transferring mail to inject spam). This is an elegant solution for traveling employees as it allows their e-mail to appear to originate from your site and yet it prevents someone else from spamming you later from the same network or dynamic IP address. DRAC uses RPC to communicate between the POP/IMAP and SMTP servers. Since RPC is considered an insecure protocol, be sure to block access to RPC from other systems with IP Tables or IP Chains. Information on DRAC and downloads are available from http://mail.cc.umanitoba.ca/drac/index.html 4.2.11 Disallowing Open Mailing ListsAn open mailing list is defined as one where anyone can send mail to that mailing list and it will be forwarded to everyone on that list. Large open lists are discouraged because of the spam potential, especially where some of the recipients are outside the organization maintaining the list. Large open lists can end up in the Realtime Blackhole List and that is very bad. This is because many of the list recipients' Sendmail configurations then will reject any e-mail from that list and because it is hard to get out of the Blackhole. The Sendmail alias capability (when a name expands to more than one recipient) is an example of an open list. Majordomo can be configured so that lists are closed. A closed list only accepts e-mail from someone on a list of senders. Commonly, this list of allowed senders is the list of recipients, for unmoderated lists. GNU Mailman is another popular mailing list manager. 4.2.12 Sendmail DoS by Filling the Disk UpAn attacker can create a DoS attack by sending so much e-mail that the system's disk is filled up. One of the reasons most files that can "grow" without user input are under /var is that this allows /var to be a separate file system. By having it be a separate file system, if /var runs out of space it will not affect the operation of the rest of the system.
A better solution is to impose quotas on users under the /var file system. Thus, each user could be limited to a reasonable amount of e-mail. An even better solution is to put a quota on the mail group. Because the mail group is only used for e-mail then a mail group quota will work regardless of whether /var is a separate partition. Recall that the quota set for a user or group is a per-file system value. The following command will list the amount of space each mailbox is using, with the largest mailboxes listed first.[2]
ls -sS /var/spool/mail The following command lists the largest 20 mailboxes and mails the result to root. It is suitable for use in root's crontab. ls -sS /var/spool/mail | head -20 | /bin/Mail -s mailboxes root |
Top |