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.

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.

Getting smap/smapd

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

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.

   
   
   

   * * * * /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:<root@bigco.com> 250 <root@bigco.com>... Sender Ok rcpt To:<root@bigco.com> 250 <root@bigco.com> 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.

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).

Using identd

Most network servers log the hostname of the client machine that initiates the connection. Unfortunately, this is frequently not enough information. Consider what happens when someone uses telnet to connect to your machine to forge email. You may have very little hope of identifying the perpetrator other than knowing the address of the machine that originated the connection. If that machine has typical logging or supports a large number of users, even the cooperation of the administrators of that machine may not be sufficient to trace the attack back to the perpetrator.

It is because of this situation that the ident protocol was defined (in RFC 1413). The ident protocol is a service that can possibly determine the identity of a user at the other end of a network connection. When a remote client connects to a server machine, the server can open a connection back to an ident server on the client machine. The client machine presents the ident server with the port numbers of the connection it wishes to identify. The ident server then responds with some value that can be used later, if needed, to identify the originating account. Normally, this string is the username associated with that account. However, the administrator of the remote machine may wish to configure it to return some other value that can be used later but that does not explicitly name a user. For example, it could return an encrypted username.

Note that identd is most definitely not a form of authentication. At best, it is a weak form of identification. The remote server may not return useful information if the service has been compromised. It also depends on the remote site administrator having installed an unmodified and working ident server - and many people do not. Some people believe that because ident cannot be trusted, they will not allow it to return any useful information at all, so they configure their server to always return "Hillary Clinton" or "Bill Gates." However, in most instances, returning valid information is helpful. In many university environments, for instance, where the ident servers are usually monitored and under central administrative control, using ident to tag users who forge email is especially helpful.

To take advantage of ident, your software needs to know how to query the remote server, if it exists. It then needs to log that information appropriately. Modern versions of sendmail have this built in, to help cut down on mail forging. The tcpwrapper program also knows how to query ident.

Keep in mind that if you record information from an ident server, it may not be correct. In fact, if you are investigating a problem that is actually being caused by the system administrator of the remote system, he or she may have altered the ident service. The service may thus return information designed to throw you off by pointing at someone else.

Currently, identd is shipped standard with few systems. For example, it is shipped with Linux, but is not usually enabled in the /etc/inetd.conf file.

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.