[Chapter 22] 22.2 sendmail (smap/smapd) Wrapper

Practical UNIX & Internet Security

Practical UNIX & Internet SecuritySearch this book
Previous: 22.1 Why Wrappers?Chapter 22
Wrappers and Proxies
Next: 22.3 tcpwrapper
 

22.2 sendmail (smap/smapd) Wrapper

The TIS[1] Firewall Toolkit eliminates many of the security problems of sendmail by going to the heart of the problem and breaking the connection between sendmail and the outside world. Instead of having a single SUID program (sendmail) listen for connections on port 25, implement a complex command set, and deliver mail into users' mailboxes, the TIS package uses a pair of programs - one to accept mail from the network, and one to deliver it.

[1] Trusted Information Systems is a company that develops and sells a variety of security products and services. The Firewall Toolkit was largely written by a former employee, Marcus Ranum, and made available to the UNIX community for royalty-free use.

22.2.1 What smap and smapd Do

The sendmail wrapper programs provide the following functions:

smap

This program accepts messages over the network and writes them into a special disk directory for future delivery. Although the smap program runs as root, it executes in a specially designed chroot filesystem, from which it cannot damage the rest of the operating system. The daemon is designed to be invoked from inetd and exits when the mail delivery session is completed. The program logs all SMTP envelope information.

smapd

This program periodically scans the directory where smap delivers mail. When it finds completed messages, it delivers them to the appropriate user's mail file using sendmail or some other program.

The TIS Firewall Toolkit stores configuration and permission information in a single file - usually /usr/local/etc/netperm-table. Naturally, this file should be writable only by the superuser. For added security, set it to mode 600.

22.2.2 Getting smap/smapd

You can obtain the TIS Firewall Toolkit from the computer ftp.tis.com using anonymous FTP.

22.2.3 Installing the TIS smap/smapd sendmail Wrapper

Installation of the complete TIS Firewall Toolkit can be quite complex. Fortunately, the sendmail wrapper programs can be installed without the rest of the kit. The sendmail wrapper can be used to protect any machine that runs sendmail, even if that machine is not a firewall.

To install the sendmail wrapper, follow these steps:

  1. Obtain the TIS Firewall Toolkit from ftp.tis.com.

  2. Read the documentation and compile the sendmail wrapper.

  3. Install the netperm-table configuration file. The default location for the file is /usr/local/etc/netperm-table.

  4. Edit the smap and smapd rules to specify the UID under which you want smap to run, where you want the spooled mail kept, where the executable is stored, where your sendmail program is located, and where you want mail to go if it can't be delivered for any reason.[2] In this example, we use uid 5, which corresponds to the user mail in our /etc/passwd file.

    [2] If you do set the undelivered mail directory, be sure to check it regularly.

    For example:

    smap, smapd:    userid 5
    smap, smapd:    directory /var/spool/smap
    smapd:          executable /usr/local/etc/smapd
    smapd:          sendmail /usr/lib/sendmail
    smapd:          baddir /var/spool/smap/bad
    smap:           timeout 3600
  5. Create the smap mail-spool directory (e.g. /usr/spool/smap). Set the ownership of this directory to be the user specified in the configuration file:

    # chown 5 /usr/spool/smap
    # chmod 700 usr/spool/smap

    Also, create the smap bad mail directory (e.g., /usr/spool/smap/bad). Set the ownership of the directory to be the user specified in the configuration file.

    # chown 5 /usr/spool/smap /usr/spool/smap/bad
    # chmod 700 /usr/spool/smap /usr/spool/smap/bad
  6. Search your system's start-up files for the line in which sendmail is started with the -bd flag, and then remove the flag. This change will prevent sendmail from listening to port 25 for incoming SMTP connections, but sendmail will continue its job of attempting to deliver all of the messages in the mail queue on a periodic basis. Note that there may not be any such line: your system might be configured to run sendmail from the inetd as mail arrives.

    For example, if your configuration file has this:

    # Remove junk from the outbound mail queue directory and start up
    # the sendmail daemon. /usr/spool/mqueue is assumed here even though
    # it can be changed in the sendmail configuration file.
    #
    # Any messages which end up in the queue, rather than being delivered
    # or forwarded immediately, will be processed once each hour.
    
    if [ -f /usr/lib/sendmail ]; then
            (cd /usr/spool/mqueue; rm -f nf* lf*)
            /usr/lib/sendmail -bd -q1h 2>/dev/console && \
                    (echo -n ' sendmail')   >/dev/console
    fi

    Change it to this:

    if [ -f /usr/lib/sendmail ]; then
            (cd /usr/spool/mqueue; rm -f nf* lf*)
            /usr/lib/sendmail -q1h 2>/dev/console && \
                    (echo -n ' sendmail')   >/dev/console
    fi

    Alternatively, you can use cron to invoke sendmail on a periodic basis with the -q option, by placing the following line in your crontab file:[3]

    [3] Note that different versions of crontab may have slightly different syntax.

    30 * * * * /usr/lib/sendmail -q >/dev/null 2>&1
  7. Kill the sendmail daemon if it is running.

  8. Modify your sendmail.cf file so that the mail user is a trusted user. You need to do this so that sendmail will respect the "From:" address that smapd sets. The trusted user is set with the "T" flag. This example sets root, daemon, uucp, and mail as trusted users.

    ###################
    #  Trusted users  #
    ###################
    
    # this is equivalent to setting class "t"
    # Ft/etc/sendmail.ct
    Troot
    Tdaemon
    Tuucp
    Tmail
  9. Edit your /etc/inetd.conf file by inserting this line so that smap is started when connections are attempted on port 25:

    smtp    stream  tcp     nowait  root    /usr/local/etc/smap     smap
  10. Cause inetd to reread its initialization file by sending it a HUP signal:

    # ps aux | grep inetd
    root       129   0.0  1.8 1.52M  296K ?  S     0:00  (inetd)
    root      1954   0.0  1.3 1.60M  208K p5 S     0:00 grep inetd
    # kill -HUP 129
    #
  11. Test to see if smap is receiving mail by trying to send mail to the root account. You can do this with telnet:[4]

    [4] Of course, replace bigco.com with your own computer's hostname.

    # telnet localhost smtp
    Trying 127.0.0.1... Connected to localhost.
    Escape character is "^]".
    220 BIGCO.COM SMTP/smap Ready.
    helo bigco.com
    250 (bigco.com) pleased to meet you.
    mail From:<[email protected]>
    250 <[email protected]>... Sender Ok
    rcpt To:<[email protected]>
    250 <[email protected]> OK
    data
    354 Enter mail, end with "." on a line by itself
    This is a test.
    .
    250 Mail accepted
    quit
    221 Closing connection
    Connection closed by foreign host.
    #
  12. Check to see if the mail has, in fact, been put into the /var/spool/smap directory (or whichever directory you specified.)

  13. Install smapd in /usr/local/etc/smapd or another suitable directory.

  14. Start smapd by hand and see if the mail is delivered.

  15. Modify your system's start-up files so that smapd is run automatically at system start up.

22.2.4 Possible Drawbacks

There are some drawbacks to using the smap program as described earlier. The first is that people who are contacting your site on TCP port 25 will no longer be able to execute the VRFY or EXPN SMTP commands that are supported by regular sendmail. (Actually, they will be able to execute them, but nothing useful will be returned.) These commands allow a remote client to verify that an address is local to a machine (VRFY) and to expand an alias (EXPN). Arguably, these are possible security risks, but in some environments they are useful (as we illustrate in Chapter 24, Discovering a Break-in).

A more serious shortcoming is that versions of sendmail with built-in support for the ident protocol will no longer be able to obtain information about the sending user. The use of the ident protocol is discussed in the sidebar "Using identd".

If using ident makes sense in your environment, you won't be able to use it with smap unless you spawn smap from another wrapper that implements ident, such as the tcpwrapper program, which is described in the next section.


Previous: 22.1 Why Wrappers?Practical UNIX & Internet SecurityNext: 22.3 tcpwrapper
22.1 Why Wrappers?Book Index22.3 tcpwrapper