Exchange Relay Review

More and more organizations are instituting policies that require security and vulnerability assessments on servers and systems before they're placed on the network. Many of these policies demand that you use auditing tools to scan your servers for exploits, confirm patch levels, provide security lockdown tips, and so on. For Exchange Server 2003 and Exchange 2000 Server email servers, a vulnerability that you need to take just as seriously is the open relay.

What is an open relay? An SMTP feature permits one server to act as an intermediary and accept messages on behalf of the final destination. The server then retransmits (or relays) the messages to the destination. In Exchange, you can configure servers to permit specific machines and users to relay mail. However, when configuration problems arise and anyone can use the system to relay mail, the result is an open relay. An open relay is dangerous for at least two reasons: First, SMTP is inherently unsecure, which makes it easy to spoof or forge the sender in a message. Lately, with the proliferation of viruses such as Bagel, we've seen how forging the sender can cause confusion and increase workloads. An open relay compounds this problem because a forged message sent from an open relay adds a certain level of authenticity—the message appears to have originated from a server in the specified sender's domain.

Second, spammers often use open relays to propagate their payload. When a spammer uses an open relay, your server's resources are diverted from processing your organization's mail traffic. Not only are resources diverted and your mail delivery hampered but you also run the risk of losing business in the long term. Using spam-blocking software and blacklists such as MAPS (http://www.mail-abuse.com) can result in the rejection of all legitimate mail from your domain because of its reputation as an open relay. An open relay can inhibit your organization's ability to do business and jeopardize its reputation.

If open relays are such a threat, why would you want to let your server relay mail in the first place? Generally, you permit relaying when you have an application that needs to send SMTP mail but doesn't have the capability to determine how to get the message to the destination. You configure the application to give the message directly to your relay server, and the relay server uses SMTP routing to deliver the message to its recipients. Examples of these types of applications are POP and IMAP clients, or a Web server form that sends email confirmations when information is uploaded. In some situations, such as designing a Web server application, you might be able to instead engineer the application so that it uses Messaging API (MAPI) instead of SMTP, thereby foregoing the need for relaying. But trends have been leaning toward standard protocols (e.g., SMTP)—not away from them.

In the case of POP and IMAP, relaying is necessary because POP and IMAP aren't intended for sending mail but rather for retrieving mail from mailboxes. To send mail, the POP and IMAP protocols must be paired with SMTP and the client must be configured with the name of a server that permits relaying. Providing relay support for these applications doesn't mean that your server will necessarily become an open relay. When you need to use relaying, your goal must be to configure an Exchange system to allow relaying only from authorized senders. To determine who is authorized, you either need to identify a system by its IP address or authenticate a sender via logon credentials. In the sections that follow, I detail how to configure a server to act as a relay without putting the server at risk for exploitation.

Are Exchange 2003 and Exchange 2000 Relay Secure?
SMTP is the core transport protocol in Exchange 2003 and Exchange 2000. Exchange often relays messages between several servers en route to a message's destination, but out of the box both versions are configured so that they aren't publicly open relays. Consider the setup that Figure 1 shows: Several servers that host mailboxes and a separate server that acts as a bridgehead are grouped in a Routing Group. The bridgehead server accepts mail traffic from the Internet and relays it to the mailbox servers; it also accepts outbound mail from the mailbox servers and delivers it to the destination hosts on the Internet.

Because SMTP is the core transport protocol, every server has an SMTP virtual server listening on port 25. The virtual server's properties let any computer connect and open an SMTP session, but the virtual server doesn't permit unauthenticated relaying. If you examined the bridgehead server's SMTP virtual server's Relay Restrictions window, which Figure 2 shows, you'd see two settings that control relaying. The first is the Select which computer may relay through this virtual server option. When you set this option to Only the list below, you must explicitly define the IP address, subnets, or domain names of any systems that are permitted to use the virtual server as a relay. When the list is empty (the default setting), relays based on server identification via IP address aren't permitted. Table 1 shows the considerations you need to keep in mind when adding these definitions.

The second way that an SMTP virtual server controls relaying is through authentication. In Figure 2, notice that the Allow all computers which successfully authenticate to relay, regardless of the list above check box is selected. This option tells the SMTP virtual server that the mail client must successfully authenticate (by providing a username and password) before the server can accept and relay mail. Both Exchange 2003 and Exchange 2000 include this option.

The primary difference between the versions is that Exchange 2000 uses an all-or-nothing approach to authentication. In Exchange 2000, if the authentication check box is cleared, you can't use authentication to determine who can relay. If the check box is selected, anyone in the domain who can successfully authenticate can relay mail—even accounts with no corresponding Exchange mailbox. Exchange 2003 refines relay authentication to provide more granular control over who can and can't relay. In Exchange 2003, when the authentication check box is cleared, a Users button becomes enabled. This button lets you use the dialog box that Figure 3 shows to grant relay permissions to specific accounts and security groups, based on authentication. To grant a user or group the ability to relay, you add them to the Permissions list and select the Allow check boxes for both Submit Permission and Relay Permission. When a mail client connects to the SMTP virtual server, successfully authenticates, and tries to relay a message, the virtual server accepts the message. If the mail client doesn't authenticate, or if it authenticates but isn't a member of the permitted security groups, Exchange rejects the message with a 550 Unable to Relay SMTP response code.

At the beginning of this section, I said that—out of the box—Exchange 2003 and Exchange 2000 aren't publicly open relays. Depending on your level of security paranoia, you still might consider them open relays. They're open in the respect that anyone who can authenticate against the server can drop off a message for delivery. The fact that anyone with a domain account can authenticate and relay might be a problem in a higher-security environment because authenticating does nothing to ensure that the From address specified in the message matches the address assigned to the account used in the authentication (if an address is assigned at all). Consider a domain account named SteveN. The SteveN domain account might have an address of [email protected]. The SteveN account can be used to successfully authenticate against the SMTP virtual server to relay a message to [email protected], but there's nothing requiring SteveN to use the [email protected] address. He could easily use george.bush@
whitehouse.gov if he wanted to. The ability to specify any address in the From field is inherent to the design of SMTP, but malicious users can easily abuse it. Because relaying directly links the message back to an organization's mail servers, some security managers consider it risky to let everyone have relay access.

Securely Relaying
What if you need to provide relay capability to a group of clients but also need to tighten security as much as possible? I recommend that you create a second virtual server on one or more of your Exchange servers. Technically, you can perform the relay configuration steps that I describe below on the default virtual server, but adding a second virtual server gives you additional options, such as the ability to have separate log files and to restrict SMTP connections. If you permit relaying on your default virtual server, all the log entries for relayed mail will be intermixed with log entries generated as a result of mail sent between servers, replication, and other system operations. If your system is busy and you want to periodically audit the relay logs, the task can be monumental. Another benefit of a second virtual server is the ability to limit which systems can establish an SMTP session. To illustrate the configuration and highlight these options, let's walk through the process of adding a second virtual server that you'll use to permit only certain systems and people to relay.

Preliminaries. Before you can configure the second virtual server, you need to perform three non-Exchange tasks. In Active Directory (AD), use the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to create a Global Security Group named SMTP-APPROVED. Place any accounts that have permission to relay in this group. Next, add an additional IP address to the physical server's Windows TCP/IP stack so that you can distinguish connections between the two virtual servers even though they're hosted on the same physical piece of hardware. For example, assume that your server already has an IP address of 10.12.170.5 and you're adding an additional address of 10.12.170.74. Open the Control Panel Network Connections applet and access the Properties dialog box for your server's network connection. Access the Internet Protocol (TCP/IP) Properties dialog box, and click Advanced. In the IP addresses section, click Add and enter the IP address (e.g., 10.12.170.74) and the appropriate subnet mask. Click OK to return to Control Panel. Finally, have your DNS administrator add a record for this IP address, such as smtp-relay.neulan.net. People who relay can use this DNS name when configuring their clients. You're now ready to configure Exchange. First, you'll reconfigure the existing SMTP virtual server so that it no longer accepts relays; then, you'll add a second virtual server that permits only authorized relays.

Lock down the existing SMTP virtual server. Open Exchange System Manager (ESM) and expand the Administrative Groups, Servers, and Protocols containers until you see the SMTP container. Right-click the Default SMTP Virtual Server and select Properties. On the General tab, click the IP Address drop-down list and change it from All Unassigned to the primary SMTP address—in this example, 10.12.170.5—then click Apply. Doing so prevents the existing virtual server from attempting to answer connection requests on the new IP address. Next, tighten the virtual server's relay options by selecting the Access tab, clicking Relay, and clearing the Allow all computers which successfully authenticate to relay, regardless of the list above check box. If you're configuring an Exchange 2003 server, the Users button will become active. Click this button to display the Permissions for Submit and Relay dialog box. Select each group or user listed, and clear the Allow check box for Relay Permission. If you're working with the virtual server in its default configuration, the only group listed should be Authenticated Users. Click OK to close all the virtual server's Properties pages. You'll need to right-click the virtual server in ESM and stop and restart the server to place the changes into effect. (Note that these configuration changes won't prevent the servers in Exchange routing groups from relaying mail. These settings don't control server-to-server relay authentication. When two Exchange servers open an SMTP session between each other, they use the X-EXPS Enhanced SMTP—ESMTP—verb and Kerberos authentication.)

Add a second virtual server. To create the second virtual server, start the ESM's new Virtual Server Wizard by right-clicking the SMTP container and selecting New, SMTP Virtual Server. In the Name field, enter the description SMTP Relay Virtual Server and click Next. Select the secondary IP address that you added (in our example, 10.12.170.74), then click Finish. Right-click the SMTP Relay Virtual Server object and select Properties. On the General tab, select the Enable Logging check box and click Apply. If you have Exchange 2003, select the Access tab and click Relay. Assuming that you want to limit who can relay, clear the Allow all computers which successfully authenticate to relay, regardless of the list above check box, then click Users. Click Add and enter the name of the AD group that you'll use to control relay access, then click OK. In this example, the group to use is SMTP-APPROVED. Select this group, then select the Allow checkbox for Relay Permission, as Figure 3 shows. Click OK twice to close the Permissions for Submit and Relay and Relay Restrictions windows.

If you want even tighter control over who can access the relay virtual server—although in most environments, such control is probably unnecessary—you can use IP restrictions to limit which systems can open a connection. For example, if you have a subnet that remote-access or VPN-connected machines use and only these systems need to relay, you can limit SMTP Relay Virtual Server access to the machines on this subnet. You might also use IP restrictions to prevent connections to the virtual server if the physical server is IP accessible from a network beyond which you have direct control—for example, the Internet (ideally, you're protected by a firewall) or a subnet that another division or business unit uses. To configure access, click the Connection button on the SMTP Relay Virtual Server's Access tab. In the Connection dialog box, you can add individual IP addresses, a subnet (group of computers), or domain definitions, using the conventions and considerations that Table 1 provides. The difference between these settings and the relay-restricting settings is that these definitions control which systems can open an SMTP connection to the virtual server on port 25 and have no real impact on a client's ability to relay.

Finally, select the Delivery tab and click Advanced. In the Masquerade domain field, enter the DNS name (e.g., smtp-relay.neulan.net) that you assigned to the virtual server's IP address. The Masquerade domain setting controls the name of the server returned in the connection banner when an SMTP connection is opened. If you don't set the Masquerade domain setting, the connection banner will have the name of the physical server that hosts the SMTP virtual server. Click OK twice to close the virtual server's Properties pages. Right-click the virtual server in ESM, select Stop, then click Start to restart the virtual server and put the configuration settings into effect.

Confirming the Configuration
If you want to confirm that your server is rejecting relays but still accepting mail for your local recipients, you should try to relay mail through the two virtual servers. Test with accounts that are in the SMTP-APPROVED list and a few that aren't. If you elected to configure connection filtering, try connecting from authorized and unauthorized IP ranges. You should find that the original virtual server won't relay mail and that the new SMTP-relay virtual server will relay only when authenticated via credentials or identified via IP address. You'll probably want to use a client such as Outlook Express, but you can also use Telnet to open an SMTP session. I prefer the Telnet approach because I can test the connection fairly easily from just about any system without the hassle of loading or configuring a full mail client. In my next article, I'll describe how to use Telnet to test authenticated relaying.

Best practice mandates that you take steps to ensure that no Exchange server capable of hosting SMTP connections can be overtaken by others who want to use the server to relay email—particularly spam or a virus. You now know how to provide relay capabilities to clients while also protecting your servers against illegal relays.