Postfix sasl authentication (1)

The basic smtp protocol does not have the ability to verify user identity. Although the sender address on the envelope already implies the sender's identity, because the envelope address is too easy to fake, it cannot be used as identity creden. To determine whether the client has the right to use the relay service, the server must confirm whether the client (sender) is the person claimed by the other party. Before sending a mail address as an ID card, smtp must require other supplementary mechanisms to verify the identity of the client. Let's take a look.PostfixHow sasl authentication works.

From the postfix perspective, it must assume two roles: as an smtp server, it must be able to verify the user's personal identity (so that they can send emails using the smtp server ); when it is an smtp client, it needs to be able to provide its own identity card to other mta checks (to deliver the mail to the final destination through the remote mta ). Therefore, we will also explain how to set the postfix so that it can pass the authentication of another mta.

Most email systems only allow clients on the internal network to use the forwarding service. In other words, the IP address becomes the identification credential of the client. However, not all valid users have fixed IP addresses. For example, if a colleague traveling far away with a laptop may use a temporary IP address near an isp or hotel, or if they are working at home, they are located outside the office, however, you need to send messages through the office email system. Sasl provides reliable authentication regardless of whether you can know your IP address in advance.

RFC 2554 "smtp service extension for authentication" defines how to add the authentication function to the basic smtp protocol, which enables smtp to use the sasl protocol to verify the client identity. We will demonstrate how to use the cyrus sasl function library developed by carnegie mellon University to expand postfix so that it has sasl verification capabilities.

Because cyrus sasl exists in the form of a "function library", to enable your postfix to support sasl, you must link the cyrus sasl function library when compiling the postfix. In addition, remote users must also set their mua so that they can send the correct identification information when forwarding emails through your email system.

Introduction to sasl

Many Client/Server protocols have no verification capability. sasl is a common method used to enhance or add such protocols. When sasl is set, you have to decide two things. One is the verification mechanism used to exchange "identity information" (or "ID card book; the first is to determine the verification architecture of the identity information storage method. The sasl verification mechanism regulates the response process between the client and the server and the encoding method of the transmitted content. the sasl verification architecture determines how the server itself stores the client ID card and how to verify the password provided by the client. If the client successfully passes the authentication, the server can determine the user's identity and determine the user's permissions. For postfix, the so-called "permission" refers to the access permission of the forwarding service. You can also decide whether to use a specific sender address when the verified user forwards the email.

Select an appropriate verification mechanism

Cyrus sasl supports multiple verification mechanisms. As to which authentication mechanism is used, both the client and the server must reach a consensus in advance. The following are some common mechanisms;

Plain

Plain is the simplest mechanism, but it is also the most dangerous mechanism, because the ID card book (login name and password) uses base64 string format through the network, there is no encryption protection measures. Therefore, when using the plain mechanism, you may want to combine tls.

Login

Login is not officially supported by login, but some old mua versions use this mechanism, so cyrus sasl allows you to choose whether it supports the login mechanism. If your users are still using this type of old mua, you must specify the login support when compiling the sasl function library. The certificate exchange process for login is similar to plain.

Otp

Otp is a verification mechanism that uses a single password. This mechanism does not provide any encryption protection, because it is not necessary-each password can only be used once, and a new password should be used each time it comes online. Smto client must be able to generate otp certificates.

Digest-md5

When this mechanism is used, the client and server share the same recessive password, and the password is not transmitted over the network. The verification process starts when the server first raises a challenge (question). The client uses this challenge and the implicit password to calculate a response (response ). Different challenge cannot calculate the same response. Any Party with a secret password can use the same challenge to calculate the same response. Therefore, as long as the server compares the response returned by the client with the self-calculated response, it can know whether the client has the correct password. Because the real password does not pass through the network, it is not afraid of network monitoring.

Kerberos

Kerberos is a network-type authentication protocol. Unless your network has used kerberos, you should not be able to use the kerberos mechanism. If your network has set up a kerberos authentication center, sasl can perfectly integrate smtp verification into the existing system.

Anonymous

The anonymous mechanism has no significance for smtp, because the purpose of smtp verification is to restrict the objects used by the forwarding service, rather than to form open relay. sasl provides this mechanism mainly to support other protocols.

When the client is linked to an email server that supports sasl, the server lists the available mechanisms with priority for the client to choose from. If the client also supports the multi-clock mechanism, when the first mechanism verification fails, the client may continue to try the second mechanism until it passes the verification or all the mechanisms fail. If the two parties cannot coordinate a common mechanism at the beginning, the verification process will fail.

Once both parties reach a consensus on the mechanism used, the verification process starts. The actual interaction process depends on the mechanism, but usually contains one or more response processes. The verification protocol itself also specifies the encoding format of the response content.

Select an appropriate verification architecture

The sasl verification architecture can use the existing unix system password or the dedicated smtp User Password File. You can also use intermediate control authentication frameworks such as kerberos on your network.

Which Authentication Architecture is most suitable for you depends on where your server is located and how certificate information is obtained. For example, if the certificate data of all users of smtp and pop/imap is stored in the system password file and verified by pam, sasl should obtain the certificate data through pam. On the other hand, if all smtp users only have virtual accounts, you may need to store certificate data in a dedicated database and set sasl and POP/IMAP server to obtain certificate data from the database.

Postfix and sasl

Before using sasl, you should decide which mechanism and architecture to use, because your decision will affect the compilation, installation, and setting process. First, you must install the sasl function library on your system, or determine the installation directory and version of the sasl function library. Next, use the sasl installation information you collected to set the compilation options of the postfix, and then re-compile the postfix to enable sasl verification. Some system platforms may have installed sasl libraries in advance and even provide postfix packages that support sasl. However, most pre-compiled postfix packages do not support sasl. Therefore, if you use a ready-made postfix package, you 'd better first read the relevant documentation, or follow the test methods described in the "test verification configuration" section in this chapter to confirm that your postfix does support sasl. In addition, make sure that your sasl function library supports every authentication mechanism that the client may use. For example, if another user uses the old version of outlook express, your sasl function library must support the login verification mechanism.

The development progress of the cyrus sasl function library is divided into two lines: sasl and saslv2. Sasl has been gradually replaced by saslv2. In the future, postfix may only support saslv2, so this chapter only discusses saslv2. In addition, both versions of the postfix and sasl function libraries must be correct before they can be combined.

Postfix supports saslv2 function libraries from 1.17-20020331 lab versions. In earlier versions, only saslv1 is supported. Theoretically, the latest postfix and the latest cyrus saslv2 can be smoothly combined.

Sasl configuration of postfix

Assume that you have installed the sasl function library and the postfix supports sasl, And you are determined which authentication mechanism and architecture to use. Now, let's gradually set the postfix so that it can use sasl to verify the user's identity.

Set verification architecture

For each application system that uses the cyrus sasl function library, cyrus sasl provides an independent configuration file. The sasl configuration file that affects postfix is smtpd. conf. This file is usually located in/usr/local/lib/sasl2/smtpd. conf. Basically, smtpd. conf should at least specify the verification architecture to be used. We plan to discuss two most common architectures: unix system passwords and independent sasl dedicated passwords.

Unix System Password

Generally, it is most convenient for sasl to directly use the existing system password to verify user identity. The traditional system password file should be/etc/passwd, but modern systems with high security can use/etc/shadow, pam or such certificate databases. Because this type of password file can only be accessed by privileged processes, and postfix is deliberately designed to avoid privileged identities, the postfix cannot directly access the system password file.

The cyrus function library provides a special verification server program called saslauthd, which can replace postfix to obtain password data. Saslauthd eaemon itself requires a privileged identity. However, because it is a process independent of the postfix and usually does not need to communicate with the outside world, the security hazard has been minimized. If you want sasl to use a unix password, you must start the saslauthd daemon that is included in the cyrus sasl package. Note that saslauthd is used to access the unix system password, indicating that you can only use the plaintext password, because asalauthd requires the actual password for verification.

To let sasl know that postfix will access the Certificate database through saslauthd daemon, you must add the following content to the smtpd. conf configuration file:

Pwcheck_method: saslauthd

Saslauthd included in the cyrus sasl package should be installed in a directory listed in the $ PATH environment variable. You must start saslauthd daemon in the background before using the postfix to verify the client. When you start saslauthd, you must use the-a option to specify the type of the password system. The most common types include pam, shadow, and getpwent. For example, on a system using pam, you should use the following command to start saslauthd daemon:

Saslauthd-a pam

Sasl private password

If you do not want to use the system password to verify the smtp client, you deliberately create an independent account database that has no system password. It may be a good idea to use the sasl password when your postfix system is purely used to provide the mail service, not to receive external emails, or to log on to the server system itself. Add the following content to your smtpd. conf configuration file:

Pwcheck_method: auxprop

In terms of cyrus, auxprop indicates auxiliary property plug-ins (exclusive plug-in module for accessibility), which is used for verification by external programs. The default auxiliary plug-in module is sasldb (which is also one of the programs included in the cyrus sasl Package). It should be able to meet all the postfix requirements. The keyword auxprop only requires an external sasl password file.

Saslauthd daemon is not required for sasl passwords, but you must store all smtp client accounts and passwords in a dedicated external password file. The default password file used by sasl is/etc/sasldb2. The postfix smtp server must have at least the permission to read this file. If you use the auto_transition function of cyrus sasl, postfix requires the permission to write this file. If you do not use the auto_transition function, it is best not to open the write permission to postfix.

If other processes also need to be able to access the sasl password file (for example, pop/imap server), you must adjust the file's ownership and access permissions so that relevant processes can access it. For example, you can create a sasl group and make sure that the postfix and other accounts that need to access the file belong to this group. If any process needs to update the file, the read-only mode may be too strict, and you must provide the write permission to the necessary process. The following command sets the access mode of/etc/sasldb2 to 440, so that all members of the sasl group can read the file, and other processes do not have access to the file:

Chown postfix: sasl/etc/sasldb2

Chmod 440/etc/sasldb2

The saslpasswd2 tool provided by the cyrus sasl package can be used to generate and maintain the/etc/sasldb2 password file. For each account, you must provide three types of information: Logon Name, sasl domain name, and password. For postfix, the domain name must match the value of the myhostname parameter. Therefore, the safest way to set the domain name is to use postconf-h myhostname to determine the domain name, as shown below:

Saslpasswd2-c-u 'postconf-h myhostname' kdent

-The c option requires saslpasswd2 to create an account. The "-u" option specifies the domain to which the account belongs. The value is taken directly from the postfix configuration file.

Set postfix

All postfix parameters related to sasl password verification are prefixed with smtpd_sasl * (about smtp server parameters) or smtp_sasl * (about smtp client parameters. For server configuration, you must at least set the smtpd_sasl_auth_enable parameter, and list the permit_sasl_authenticated restriction conditions in a certain smtpd _ * _ restriction Filtering Rule.

Enable sasl Verification

The smtpd_sasl_auth_enable parameter determines whether the postfix smtp server supports sasl Verification:

Smtpd_sasl_auth_enable = yes

Some old mua do not fully comply with the smtp authentication protocol. According to the standards in the Specification, after the smtp client sends the ehlo command, the smt server should list its authentication mechanism support list, and this list appears after the keyword auth and a space.

However, some mua expect to receive the auth and an equal sign;

Postfix allows you to accept such non-compliant behaviors:

Broken_sasl_auth_clients = yes

After this parameter is set, postfix lists the smtp authentication mechanisms supported by this parameter in both standard and non-standard formats.

Because both formats are in the smtp server response, standard mua is not affected, and non-standard mua can be verified using smtp sasl.

Avoid sender impersonation

How do I determine the real sender address used by the client when the client sends a message through postfix? For example, how can someone who passes smtp authentication as A but uses B as the issuer's address avoid this impersonation? Postfix allows you to set the correspondence between the sender address and sasl logon identity. For example, assume that a person's email address is a kdent@example.com and his sasl login identity is kdent. If you want a kdent to send an email only in the name of this address, instead of using another mailing address, you should define the following mappings in a query table:

Kdent@example.com kdent

This is a common postfix query table. You can list the correspondence between each address and each sasl user one by one, or use a regular expression to represent the personal name or domain name of the email address. After creating a query table, point the smtpd_sender_login_maps parameter of main. cf to this table:

Smtpd_sender_login_maps = hash:/etc/postfxi/sasl_senders

The next step is to include the reject_sender_login_mismatch restriction in a combination of smtpd _ * _ restrictions filtering rules, so that if kdent passes sasl verification, but he tries to send an email in the name of the mary@example.com, then the postfix will reject sending messages to him.

Approve authorized users

If your ube filter rule contains smtpd_recipient_restrictions, you must enable the postfix to allow authenticated users to use the forwarding service, that is, to place permit_sasl_authenticated in a proper place in the constraints.

Set Verification Mechanism

When the client comes online to the smtp server, which password verification mechanisms can be used is determined by the smtpd_sasl_security_options parameter. The complete mechanism options depend on which mechanisms are available on your system and what mechanisms are supported by the sasl function library. If no option is specified, all available mechanisms including plaintext passwords are accepted by default, except Anonymous logon. If saslauthd daemon is used, the plaintext password must be accepted. Therefore, the default value is reasonable. If you specify any options, the default value is invalid. Therefore, your options must contain noanonymous. For example:

Smtpd_asal_security_options = noanonymous, noplaintext