Run the auth service (identd) to provide account information that cannot be hidden by masquerading or other email techniques.

The IDENT protocol is defined in RFC 1413, Identification Protocol. The protocol provides a means for determining the identity of the user who initiated a network connection. The identd daemon implements the IDENT protocol on Unix systems. Run identd to provide additional information to remote system administrators to aid them in tracking down the cause of problems. In the context of sendmail, this information might help them track down a spammer, if one sets up shop on your system. For example, assume a user on a system running identd tries to perpetrate a forgery by issuing the SMTP EHLO command using a false hostname:

ehlo www.ora.com

250-rodent.wrotethebook.com Hello IDENT:r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc@chef.

wrotethebook.com [192.168.0.8], pleased to meet you

When the remote system, in this case rodent.wrotethebook.com, responds to the EHLO command, it ignores the forged www.ora.com hostname. Instead it says “hello” to the host it finds at the connection address 192.168.0.8. It responds with the hostname associated with that address, which is chef.wrotethebook.com, and the identification information provided by the identd service running on chef. This information is propagated in the mail in a Received: header, as shown below:

Received: from www.ora.com

(IDENT:r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc@chef [192.168.0.8])

by rodent.wrotethebook.com (8.12.9/8.12.9) with ESMTP id gB4N6T301540

for <craig@rodent.wrotethebook.com>; Wed, 4 Dec 2002 18:06:40 -0500

The information provided by the identd service running on the host at 192.168.0.8 identifies the user who sent the mail. The string provided by identd, r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc in the example, is not a simple username. In this case, the identd information is encrypted.

identd monitors port 113. When identd is running, the remote server can request information about any TCP connections from your server to the remote server by sending the source and destination port pair to the identification server. identd then responds by sending either the requested information associated with the connection or an error. This information allows remote mail servers to put a real username on the Received: header in incoming email. People who abuse the mail system do not like to have their real usernames known. Providing their names to their victims makes it hard for them to stay in business. Unfortunately, many firewalls block port 113 because the security people fear that too much information is given out by the identd service. This fear is unfounded when the identd information is encrypted, as it is in this example. However, many security administrators prefer to play it safe, so they block the port. If it is blocked at your firewall, you might not be able to use identd.

The IDENT protocol is also known by the service name auth, as this grep of /etc/services shows:

$ grep ^auth /etc/services

auth    113/tcp    ident   # User Verification

Most sendmail administrators prefer to call the service ident or identd to avoid confusing it with the ESMTP AUTH keyword. Additionally, identd is not an authentication tool—it is an auditing tool. Real spammers, who control their own systems, can put anything they want in an identd response, so the response cannot be trusted for real authentication. You, however, are not a spammer. You run identd to provide additional audit trail information to track down users who abuse your system.

Many Unix systems run identd on-demand from inetd or xinetd. The following line added to inetd.conf would implement ‘blocking spam with the access database’ on a system using inetd and an on-demand identd service:

auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -t120

This, of course, is just an example. You would need to customize the program pathname and the command-line arguments to fit your system and your needs. You should also check the identd manpage for options that prevent the user from disabling identd.

Some other Unix systems run identd as part of the system startup process. Our sample Red Hat Linux system is an example. A chkconfig command adds identd to the boot process, and a service command starts identd immediately:

# chkconfig --list identd

identd          0:off   1:off   2:off   3:off   4:off   5:off   6:off

# chkconfig --level 35 identd on

# chkconfig --list identd

identd          0:off   1:off   2:off   3:on    4:off   5:on    6:off

# service identd start

Generating ident key:                                      [  OK  ]

Starting identd:                                           [  OK  ]

The first chkconfig command shows that identd is not included in the boot process on this sample Linux system. The second chkconfig command adds it to the startup process for run levels 3 and 5—the run levels associated with networked, multiuser operation on most Linux systems. The final chkconfig command shows the effect of this change. Of course, there is no reason to reboot the system just to start identd, so the service command is used to run the identification service immediately.

This is the first time that identd has been started on this server. Notice the first line of output from the service command. It tells us that a key is being generated for identd. This key is used to encrypt the information sent to the remote system. The administrators of the remote system cannot decrypt the information because they do not have the key. If they suspect a problem, they must send you the encrypted string, which you can then decrypt using the /etc/identd.key file and the idecrypt command. The information from the identd server is encrypted for security reasons. Security people dislike identd because it exposes information about systems and users that can be misused by spammers and intruders. Encrypting the identd response allows you to run the identification daemon without any significant security risks.

For example, the Received: header shown earlier in this section displays the 32 character, BASE64 encoded string r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc that the remote system received from our sample system in response to the IDENT query. This does not provide any information that can be exploited by a spammer or an intruder, but it can be used by you to obtain information about the local user who sent the mail. When the remote system administrator contacts you with a problem report, obtain the 32-byte string, enclose it in square brackets, and decode it with the idecrypt command, as shown:

# idecrypt 

[r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc] 

Wed Dec  4 17:00:24 2002 500 192.168.0.8 1029 192.168.0.3 25  Ctrl-D 

The decoded string provides:

• The date and time the connection was made
• The UID of the user who initiated the connection (500 in this example)
• The IP address of the source of the connection (192.168.0.8)
• The source port (1029)
• The destination IP address (192.168.0.3)
• The destination port of the connection (25, which is the SMTP port)

All of this information is useful in tracking who is abusing your system. However, identd does have major limitations. It only returns a useful UID if the user actually logs into your system. If it is being misused in some other way, the information provided might not be useful. Additionally, running identd adds some processing overhead to each piece of mail. As with most things, identd has both pluses and minuses.

On our sample Red Hat Linux system, the identd service is preconfigured in the /etc/identd.conf file. Additionally, the identd service can be configured from the command line using command-line options. On a Red Hat Linux system, the identd command-line options used during startup are defined as values for the IDENTDOPTS variable in the /etc/sysconfig/identd file. See the identd manpage for specifics on the identd.conf configuration commands and the command-line options.