Converting Sendmail to Postfix, Part One: Why Convert?

Notable Features of Postfix to Keep You Secure

Almost all mail transfer agents offer some form of security to help protect your system and your mail users from the growing number and types of attacks on the Internet today. What makes Postfix different from many of the others is that security is designed in as one of the basic tenets, not as an add-on afterthought.

This upfront prioritization of security allows you to configure Postfix so that it is not only possible to put some preventative measures in place, but to make it easy to do so. Sendmail is capable of just about any sort of manipulation of email imaginable; the problem is learning enough of Sendmail's internals and configuration syntax directives to get it to perform. Let's take a quick look at how Sendmail and Postfix can be configured to protect against a common problem facing our Windows email clients today—Internet worms.

Turning Away the Worm

To simplify this comparison, we will make use of the notorious LoveLetter worm that compromised thousands of corporations, universities, and other organizations last year. Many virus and worm-detection techniques depend on identifying specific characteristics that uniquely identify the infected carriers from otherwise normal email traffic. These characteristics, collectively known as signatures, are commonly used by virus detection software and in mail and Web proxy servers to shield the targeted user base.

In the LoveLetter worm example, one of the signature attributes was the use of the phrase "ILOVEYOU" in the Subject line of an infected email message. A simplistic preventative measure then would be to scan all inbound email message headers for a Subject line that contains "ILOVEYOU".

Blocking Using Sendmail

Sendmail's configuration file, sendmail.cf, normally looks like line noise to the uninitiated. A much simpler method of configuring Sendmail is via the sendmail.mc macro configuration file, which generates a usable sendmail.cf configuration file using the m4 macro processor. Carefully adding the following text to your sendmail.mc will stop the transmission and spread of the LoveLetter worm.

LOCAL_RULESETS
HSubject:      $>Check_Subject
D{MPat}ILOVEYOU
D{MMsg}This message may contain the LoveLetter virus.

SCheck_Subject
R${MPat} $*     $#error $: 550 ${MMsg}
RRe: ${MPat} $*    $#error $: 550 ${MMsg}

Why do you need to be careful? Why couldn't you just cut and paste the above into your sendmail.mc and be done with it? Sendmail is quite picky about the format of its configuration file, and specifically about the rewriting rulesets (the lines above that begin with R). Specifically, you cannot use spaces between the $* and $#, you must use TABs; otherwise, you will generate an invalid Sendmail rule.

Now, let's play the real world catch-up game of virus and worm signatures. Shortly after we protect our users from the LoveLetter worm, we find out that there is a new variant that uses a different subject. The new signature attribute is "Important message from" in the Subject line.

What steps do we need to do to protect our Windows users? What do you would need to add to your sendmail.mc LOCAL_RULESET? First, add the new D defines and R rules to catch the variant to your sendmail.mc file. The modified sendmail.mc would then look like the following:

LOCAL_RULESETS
HSubject:      $>Check_Subject
D{MPat}ILOVEYOU
D{MPat2}Important message from
D{MMsg}This message may contain the LoveLetter virus.

SCheck_Subject
R${MPat} $*     $#error $: 550 ${MMsg}
RRe: ${MPat} $*    $#error $: 550 ${MMsg}
R${MPat2} $*     $#error $: 550 ${MMsg}
RRe: ${MPat2} $*    $#error $: 550 ${MMsg}

Next, you would need to convert your sendmail.mc file to a usable sendmail.cf file by passing it through the m4 macro processor, test the new sendmail.cf configuration, and finally move this new configuration into place permanently.

This is a complex, multistep process that has several opportunities to introduce errors. Or undo configuration changes made directly to the sendmail.cf rather than incorporated into the sendmail.mc file. And this does not scale well to multiple mail servers. Let's examine how this is accomplished using Postfix.

Blocking Using Postfix

Postfix is modular in nature, and that is reflected in the configuration file design as well. There are several core configuration files that govern how Postfix operates, and additional external mapping type files can be specified within those core configuration files.

The main configuration file for Postfix is named, conveniently enough, mail.cf. The main.cf configuration file has quite a bit of documentation built in to help explain some of the features and configuration options available. The feature we are concerned with, in our LoveLetter worm example, is scanning the email header Subject line. So in the /etc/postfix/main.cf file, add the following line:

header_checks = regexp:/etc/postfix/header_checks

The header_checks directive instructs Postfix to check the header of each email message using regular expressions contained in the external file /etc/postfix/header_checks. By referencing an external file, we can then add or remove patterns to that without having to restart Postfix.

We can now maintain the external /etc/postfix/header_checks file independently of the configuration. Simply add the following line:

/^Subject:.*ILOVEYOU/ REJECT

We now have the same protection that the previous Sendmail example affords our Windows user base. Adding additional signatures to catch new variants of the LoveLetter worm now just requires a new line in the header_checks file:

/^Subject:.*Important message from/	REJECT

There are several key points here:

• Virus and worm signatures are kept in an external file, independent of the Postfix configuration. This allows for easy centralized management of multiple mail servers by just pushing out the updated and tested header_checks file. None of the Postfix processes need to be stopped or restarted, and no configuration files need to be rewritten or reloaded.

• Postfix patterns use industry-standard POSIX 1003.2 regular expressions, or Perl Compatible Regular Expressions. This allows a broad reuse and application of practical knowledge. Regular Expressions can be applied to any number of applications, from text editors such as vi, shell scripts, normal UNIX utilities, scripting languages such as Perl and Python, and Web servers such as Apache. Learning Sendmail rewriting rules has no other application.

• The simplified configuration file and pattern maps allow for a lower barrier to maintenance. In the long term, this reduces both the possibility of introducing errors and the overall cost of operations.

So how can Postfix be used to stop newer, more devious worms and virii embedded in email attachments? Postfix has an additional feature to allow scanning of message bodies.

Blocking Using Postfix Body Checks

The header_checks directive instructs Postfix to check the message headers for a particular pattern. The complimentary body_checks directive will configure Postfix to check the body of the message. The body of an email is normally where the MIME attachments are that carry the worm and virus payloads. To enable body checks, just edit the /etc/postfix/main.cf, and add the following line:

body_checks = regexp:/etc/postfix/body_checks

Then in the /etc/postfix/body_checks file, add the following line:

/^(.*)name="?(.*)\.(bat|chm|cmd|com|eml|exe|hta|js|jse|lnk|pif|scr|shs|vbs|vbe|vxd)"?(.*)$/ REJECT

The above might look a little complex, but in reality it is just a common POSIX 1003.2 regular expression, compatible with many regular expression-matching utilities or scripting languages such as grep, AWK, sed, Perl and Python. This pattern basically looks for the MIME header that contains the name of the attachment that ends in any of the listed filename extensions (those two or three letters separated by the '|' symbol).

Those sites that had a line similar to that in their Postfix MTA would have ensured that their sites were safe from infection via email of the Nimda and W32.Vote worms.

Postfix Pattern Matching Maps Explained

Both the header_checks and body_checks pattern maps use the same format for defining checks and actions. The simplest form, and the only form discussed in this article, is the following:

/regular expression/ ACTION

The matching occurs with the pattern, in this case a regular expression, which is the text between the forward slashes. Ignoring what a regular expression is for now, the ACTION is one of three possible actions:

• OK—The pattern match is OK, so do not reject or modify the message. This action is not particularly useful for header or body scanning because it would otherwise cause a delay to the default action: to deliver the email.

• IGNORE—Silently remove the header or body line that matches the pattern.

• REJECT—Reject the entire message.

• 4xx/5xx messages—Reject the entire message with a custom 4xx or 5xx SMTP result code and message. The 4xx series of STMP result codes is generally used for temporary failure, whereas the 5xx series is used for permanent failure.

So, rather than just reject the LoveLetter infected email messages, we can provide a specific response as to why it was rejected by changing the REJECT action to

550 This Email potentially contains LoveLetter worm payload

Back to regular expressions, if you have never written a regular expression before, all the symbols and their relevance could seem a bit overwhelming. Explaining regular expressions and their syntax is well beyond the scope of this article. Luckily, you don't normally need to take advantage of any esoteric features of regular expressions to make a useful match. For further reading about creating regular expressions, you should refer to the regular expression syntax documentation in any number of sources: the Perl homepage (http://www.perl.com/), the Python homepage (http://www.python.org/), Perl Compatible Regular Expression library home page (http://pcre.sourceforge.net/), and even UNIX man pages for grep(1), regex(7), or perlrequick(1).

Go Directly To chroot Jail

As mentioned previously, Postfix was designed with security in mind from the beginning. The Postfix architecture is broken up into many small, more manageable programs that are specialized into specific tasks (otherwise known as "The Unix Way"—do one thing and do it well). Each of these programs can be replaced, if necessary, to provide different functionality without replacing Postfix as a whole. The smaller nature of the programs also makes source code auditing easier.

The Postfix programs never trust any of the data that they cannot verify directly. Postfix runs a specific user that has limited, low-exposure permissions on the system. The Postfix programs never run set-uid, which is a Unix attribute that allows a program to effectively run as a specific user. Sendmail, for example, runs set-uid root, meaning that it runs with root-level privileges.

Postfix was designed to be able to be run in a chroot jail. A chroot jail is quite similar to what it sounds like: you change the root of the file system environment to a lower-level directory for a specific program. The term jail is denoting that the program is basically restricted to its newly defined file system hierarchy, and thus does not have access to other critical system files.

Placing and operating Postfix in a chroot jail ensures that if an exploit was developed against Postfix and your server was compromised, the damage to the system would be both localized and minimized. As you can see, there are many layers of security in the Postfix architecture with little or no trust between each layer. Achieving each of the stated design goals is a major contributing factor to Postfix's growing success.