Configure Sendmail Security

Sendmail Security
The security of the sendmail service leaves a lot to be desired, with bugs being regularly found in it. Because of this, administrators and programmers have made the service into the butt of jokes. I have heard some of them even making bets on whether a new bug would be found in it within a month.

In this section, I will describe some parameters that can be configured to enhance the service's security.

Telltale Banner
Security problems start at the connection stage. Like most other services, the sendmail service displays a greeting message containing the program name and version.

This information should be made unavailable to hackers. This is achieved by changing the SmtpGreetingMessage parameter in the /etc/sendmail.cf file. In older sendmail versions, the value of this parameter was the following:

SmtpGreetingMessage=$j Sendmail $v/$Z; $b

The most dangerous element here is the $v/$Z option, which displays the program name and version. Therefore, it was removed in more recent versions. Now the parameter is set to the following value:

SmtpGreetingMessage=$j $b


If the value of this parameter in your system contains something in addition to this, you should remove it. You can even set this parameter to display an entirely different service, as follows:

SmtpGreetingMessage = $j IIS 5.0.1 $b

Any successful attempt to confuse hackers stalls them and gives you a small victory.

Outgoing Mail Only
Mail servers often are used only to send mail. For example, Web servers can have sendmail installed only so that mail could be send from Perl or PHP scripts. If receiving mail is not a part of your server's mission, this mode should be disabled. This can be done by modifying the contents of the /etc/sysconfig/sendmail file as follows:

DAEMON = yes
QUEUE = "qlh"

The second directive sets the parameters that will be passed to sendmail when it is started. To allow your server to receive mail, change the value of the QUEUE parameter to -bd.

If there is no sendmail file in the /etc/sysconfig directory in your system (as is the case in some distributions), you will have to edit the /etc/rc.d/init.d/sendmail script file. Find in this file the parameters passed to the program, and change them to q1h directly in the script text.

Access Rights
No operating-system service should be allowed to work with root privileges. Should a vulnerability be found in the program's code that allows command execution, the system can be considered already compromised, because commands will be executed as root.

The service should work with the privileges of a user that has access only to the directories and files necessary for the service's operation. In the most recent sendmail versions, this can be implemented with the help of the RunAsUser parameter as follows:

0 RunAsUser = sendmail

By default, this entry may be commented out. If it is, remove the comments. You can also implicitly specify the group with whose rights the program is to run:

0 RunAsUser = sendmail:mail

Here, sendmail is a user name and mail is a group name.

Superfluous Commands
The mail server can process a great number of commands, but not all of them are useful. Make sure that the following entries are in your configuration file and that they are not commented out:

O Privacyoptions = authwarnings
O PrivacyOptions = noexpn
O PrivacyOptions = novrfy

All of these options can also be listed, delimited by commas, in one line as follows:

O PrivacyOptions = authwarnings, noexpn, novrfy

The most dangerous element for the server may turn out to be the vrfy option, which is used to check whether a mailbox exists. The third directive in the example disables this option.

The second directive sets the noexpn parameter. This disables the expn command, which allows the email address and even the user name to be determined by the mail alias name. Hackers can use this directive to build spam mailing lists. They should not be given a chance to collect this information.

Executing External Commands
The mail service has one serious problem: It has to execute system commands, which is always fraught with danger. If a hacker can run such a program with extended privileges, great harm can be done to the system. This is why I recommend lowering the service's rights, but this alone is not sufficient.

To prohibit system commands from execution, sendmail has to be made to work through a secure command interpreter. For this purpose, the smrsh program was developed. The program curtails sharply the number of commands that can be run by sendmail, improving the overall security of the system. The easiest way to make the mail service use this command interpreter is to add the following line to the sendmail.mc file:

FEATURE('smrsh', '\user\bin\smrsh')

Here, in parentheses, the following two parameters are specified: the name of the command interpreter and the directory, in which it is located. Make sure that this is where the command interpreter is located in your system; otherwise, change the path.

By default, the smrsh interpreter executes commands from the /usr/adm/sm.bin directory. It will not run programs from different directories. If there are only secure programs in the /usr/adm/sm.bin directory, your system will be less vulnerable.

Trusted Users
The sendmail service allows a list of users to be created that are trusted to send messages without warnings. This list is saved in the /etc/mail/trusted-users file. I do not recommend entering real users into this list.

But the file can be useful under certain circumstances. You can add the Apache user to it to allow letters to be sent from Web scripts.

DoS Attacks
Mail servers are often subjected to DoS attacks because they have to accept connections from any users to service the mailboxes. Consequently, ports 25 and 110 are, most often, publicly available.

The sendmail service can be made more secure against DoS attacks by properly setting the following parameters:

MaxDaemonChildren — This parameter sets the maximum number of simultaneous processes. It can be used to protect the processor from excessive workloads. Its default value is 12. This value can be set higher for a more powerful processor to use its resources more effectively. For a less powerful processor, the value can be lowered.

ConnectionRateThrottle — This parameter specifies the maximum number of connections per second per daemon. By default, the value of this parameter is 3. It should not be raised unless you are certain that your server can handle the increased number of connections.