Recipe10.2.Securing SMTP Authentication

Recipe 10.2. Securing SMTP Authentication

Problem

You want to ensure that your Internet-facing Exchange SMTP server is properly secured.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.
Locate the target server, then expand its Protocols container and the SMTP node beneath it.
Right-click the Default SMTP Virtual Server node and select Properties.
Switch to the Access tab and click the Authentication button. The Authentication dialog is shown in Figure 10-1.
Choose the appropriate authentication settings by checking the corresponding boxes. For Internet-facing servers, you must leave anonymous access enabled if you want your server to accept SMTP mail from other servers; you can enable or disable basic and integrated authentication as necessary (see the Discussion section for more on this).
Click OK to accept the authentication settings. They will take effect immediately.

Figure 10-1. The SMTP server authentication dialog

Discussion

Configuring SMTP authentication is a necessary part of securing your Exchange server. SMTP wasn't originally designed to support authentication, so the IETF has retrofitted authentication via the SMTP AUTH verb as documented in RFC 2554. You can only control authentication at the virtual server level. The Authentication dialog pictured earlier in Figure 10-1 gives you control over which authentication methods a particular virtual server will accept.

The Anonymous access checkbox controls whether your server will accept completely unauthenticated connections. This is the default behavior of most SMTP servers, so for servers that you want to accept mail from the outside world, this checkbox should be set.
The Resolve anonymous email checkbox (enabled only when Anonymous access is marked) controls whether Exchange will attempt to resolve SMTP FROM addresses into names in the GAL. In general, you should leave this turned off. If you enable it, spammers or forgers can inject mail that will appear to have been internally generated. Let's say we have this option enabled, and a spammer sends mail that claims to be from paulr@3sharp.com to a user on our server. Our server will resolve that address to the corresponding GAL entry, so the recipient won't see the bare SMTP address if they're using OWA or a MAPI clientthey'll see whatever's defined in the GAL.
The Basic authentication (password is sent in clear text) checkbox enables the use of basic SMTP authentication using the SMTP AUTH verb. When you select this, ESM will warn you that this method doesn't provide any protection for user credentials as they're sent over the wire. This is a good warning to heed. If you're leery of allowing passwords over the wire in the clear, make sure you check the Requires TLS encryption box; this will only allow basic authentication on incoming connections from other servers and clients that support using TLS with SMTP.
If you enable the use of basic authentication with TLS, and you have more than one domain with user accounts, you can specify a default domain in the Default domain field. This is not required, because users can always specify a domain as part of their user name.
The Integrated Windows Authentication checkbox controls whether Exchange will accept Windows authentication methods for logon. These methods may include the use of Kerberos or NTLM credentials; only mail clients and servers that support these methods can use integrated authentication, so for practical purposes, this checkbox might as well be labeled "For Microsoft products only." (Note that if you enable this setting, clients won't use it unless you turn on the secure password authentication, or SPA, feature in the client.)
When anonymous access is disabled, the Users button becomes enabled. As its label intimates, you can use this button to allow or deny SMTP privileges to specific users or groups. This is a commonly requested feature for companies that want to further restrict who can send SMTP mail through their servers; by specifying users and groups that should either be denied or granted permissions, you can complement the IP address restrictions described in Recipe 7.21.

In some cases, you might really want to allow only authenticated senders to use your SMTP server. For example, you might set up one virtual server that allows relaying (but only with authentication!) and another that accepts mail from servers on the Internet. In that case, make sure that the Anonymous access checkbox is turned off on the server where you want to require authenticated access.

One area that calls for particular caution is the prevalence of SMTP authentication attacks. These attacks, usually mounted by spammers, are essentially dictionary attacks that attempt to discover user passwords for use with SMTP servers that require authentication. Exchange 2000 and 2003 don't log failed authentication attempts by default, so you won't necessarily have an idea that you're under attack. The logs maintained by the Internet Information Services (IIS) SMTP core don't record authentication requests, so you can't watch them for clues either. The only reliable way to monitor attempted attacks using this scheme is to look for packets originated by your Internet-facing mail servers on TCP port 25 with the string "535 5.7.3 Authentication unsuccessful" in them.

There are several protective measures you can take, though:

Ensure that all your user accounts are using strong, complex passwords. This is especially important for the Administrator account, which has a well-known name. (You might consider renaming the Administrator account; this adds a small degree of additional security, although it's trivial for any legitimate user to discover the correct name from within your network).
Set diagnostic logging on the Connection Manager component (see Recipe 4.7 for directions) of the MSExchangeTransport object to Medium or High. Once you do this, failed connection attempts will result in event ID 1706 and 1707; however, these events don't indicate the IP address or user name of the failed connection attempt.
Disable authentication on your primary Internet-facing SMTP virtual server. This prevents attackers from mounting dictionary attacks against that server, although it also prevents you from allowing authenticated relay to that server.
If you need authenticated relaying, set up an additional virtual server, preferably using a nonstandard port. Spammers won't be able to routinely discover this port (unless they do a port scan, which your firewall should prevent) but legitimate users can configure their clients t o use it.