Controlling Relaying

Because being an open relay has potentially bad consequences, the best approach is to not be one. You can accomplish this goal in several ways: disallowing relaying completely, allowing relaying only for specified domains or IP addresses, accepting relay requests only from hosts with particular IP addresses, or requiring authentication from the sender before accepting a message for relay. Exchange 2000 Server and Exchange Server 2003 support all these methods . Even better news is that by default both versions allow only authenticated senders to relay. However, for reasons discussed earlier you might need to turn relaying back on (at least some of the time).

Note  

In early versions of Microsoft Exchange 5.5, the Internet Mail Service (IMS) would act as an open relay by default, but that s long past. Of course, you should double-check your servers to make sure that they haven t accidentally been opened as relays.

You can control relaying settings on both SMTP virtual servers and SMTP connectors. Because most Exchange sites aren t using SMTP connectors, the most common place to control relaying is on the SMTP virtual server object, which resides in the Protocols container of each individual server.

Remember that the relaying settings apply to individual SMTP virtual servers and connectors. There is no built-in way to apply and enforce relaying settings on multiple servers at the same time. Each server s configuration is stored in the Internet Information Services (IIS) metabase on the local machine, so you can t apply these settings using Group Policy or Exchange system policies. Because most organizations with multiple servers concentrate their SMTP message flow through a small number of bridgeheads or front-end servers, this situation isn t as dire as it sounds. The individualized nature of relaying settings is worth remembering, though, because if you leave even a single open relay accessible to the Internet, spammers are sure to find it.

Controlling Access for SMTP Virtual Servers

You control relaying settings through the SMTP virtual server Properties dialog box. The Access tab (shown in Figure 8-2) has three buttons of interest for relaying control. The Authentication button lets you control what types of authentication are required for a successful connection (including which users or groups can use an SMTP virtual server); with the Connection button, you can allow or deny specified IP addresses or DNS domains to connect; and the Relay button allows you to control who can relay mail through your server. (The Certificate and Communication buttons , which are used to turn on and manage Secure Sockets Layer/Transport Layer Security [SSL/TLS] for SMTP, are discussed in Chapter 11, Securing Internet Communications. )

Figure 8-2: The Access tab of the SMTP virtual server Properties dialog box.

The SMTP server follows a fairly straightforward process for deciding whether to accept an inbound message for relaying. Figure 8-3 presents a flowchart that illustrates how this process works:

1. When an incoming connection arrives, if its IP address is on the global deny list of addresses, the connection is immediately dropped.

2. If the IP address passes muster, the sender can (but isn t required to) attempt to authenticate by sending the AUTH verb plus an indicator of the authentication method it wants to use (for example, AUTH GSSAPI indicates that the sender would like to authenticate with Kerberos). If the Exchange server doesn t support the requested method, it responds with an error code (504 Unrecognized authentication type). The two sides go back and forth in this manner until they either agree on an authentication method or the client gives up and closes the connection.

3. If the two sides agree on an authentication method, the server responds with an SMTP 334 message that includes whatever authentication string the sender must answer. The sender answers, and the receiving server checks the credentials. If they are invalid, the server returns an error code (535 Authentication unsuccessful ), but the server doesn t drop the connection; that allows the sending computer to try again.

4. Exchange accepts the MAIL FROM command and applies the sender and connection filters described later in the chapter to the IP address of the sender. If those filters accept the traffic, Exchange accepts RCPT TO and uses the recipient information to make some other filter checks. If the message passes all the filters, it is evaluated to see if the recipient address specifies a nonlocal recipient; in that case, the relaying restrictions are evaluated to see whether the message can be accepted or not. If any of the relay restrictions apply, Exchange returns the 550 Unable to relay error code. In addition, Exchange checks the MAIL FROM sender specification to weed out messages with obviously forged sender information (like MAIL FROM: @).

5. If none of the restrictions apply, Exchange accepts the message, and the sender can proceed to its next transaction. However, if the categorizer determines that the message is addressed to a nonlocal recipient for which relaying is not allowed, the message is returned to the originator with an NDR (and the same 550 Unable to relay error).

   Note  

   The SMTP server can close the connection if it s idle for the specified timeout period, which defaults at 10 minutes. This default is reasonable, although if you have high volumes of traffic from users on high-latency connections you might consider increasing it (or, conversely, decreasing it to drop the wait time).

   
   Figure 8-3: The SMTP virtual server evaluates the connection control settings before accepting messages for delivery. See Figure 8-10 for a description of how connection, sender, and recipient filters are applied.

The Stealth SMTP AUTH Attack

In 2003, Exchange administrators all over the world started noticing that their servers were being used to relay spam, even though their relaying configuration prevented them from acting as open relays. This sad situation came about because some smart but evil spammers figured out a way to exploit Exchange s authentication mechanism for their own good. The trick involved brute force password attacks against accounts with well-known, easily guessed, or publicly available names , but doing so using the SMTP AUTH verb. By default, the SMTP service doesn t log any evidence of successful or unsuccessful authentication requests, meaning that this attack could be in progress against one of your servers right now. If an attacker is able to guess the password to an account (including, but not limited to, the Administrator account), he or she can authenticate to the SMTP server and relay as much spam as he or she would like to. Fortunately, there are several countermeasures:

• To completely prevent the problem, just turn off all relaying on your Internet-facing virtual servers. Make end users send SMTP mail through their ISP s SMTP server, or make them connect using a virtual private network (VPN) to use an internal-only relay host. Turning off relaying alone won t completely solve the problem, though, because the SMTP server will still respond to AUTH requests. On all of your Internet- facing SMTP servers, turn off basic and integrated Windows authentication. This effectively prevents the password-guessing attack, although admittedly it prevents you from letting users perform authenticated relaying.

• If you have to leave relaying or authentication on, make sure again that your user accounts all have passwords; that you have a policy defined that requires the use of strong, complex passwords; and that all your users have changed their passwords at least once since you applied that policy.

• If you have an intrusion detection system, program it to look for failed SMTP authentication requests (look for the string 535 5.7.3 Authentication unsuccessful at offset 54 in packets on TCP port 25). This will help give you early warning of new attacks.

• Turn on account auditing (see Chapter 6, Windows Server Security Basics ), then look for strings of event ID 528. The SMTP service logs failed logons when auditing is enabled, but not to its own log.

  As you might remember from Chapter 6, it s possible to set account lockout policies that turn off accounts with excessive logon failures. Most sites leave this turned off for good reason. However, you might want to consider enabling it and setting the thresholds so that automated high-volume attacks are likely to be caught. How do you choose the thresholds? The simplest way is probably to pick a number and then wait to see how many legitimate users get locked out after the policy is first put into place. If there are too many lockouts, change the settings. This is unscientific, but workable .

 

Requiring Authentication

By default, SMTP is an unauthenticated protocol: every SMTP server on the market ships with default settings that allow it to accept anonymous connections. This arrangement is fundamental to the way Internet e-mail works. A public SMTP server can receive mail from any other SMTP server on the Internet; if your server requires authentication, a sender whose server cannot authenticate cannot deliver mail to you. However, there are circumstances when requiring authentication is appropriate. For example, let s say you want only your remote users to relay traffic through a specific SMTP server. One way to handle this is to create a new relaying-only SMTP virtual server for your mobile users and set it to require authentication.

Clicking the Access tab s Authentication button opens the Authentication dialog box (see Figure 8-4). From this dialog box, you can require your SMTP server to use any combination of the three basic authentication levels Exchange supports. Its three check boxes allow you to specify which of these methods your server will accept. In addition, Exchange Server 2003 now allows you to set access control lists (ACLs) on the virtual server, granting or denying individual users or groups the right to pass mail through it.

Figure 8-4: Setting authentication properties on the SMTP virtual server is one way to control who can relay through it.

• The Anonymous Access check box controls whether your server will accept anonymous SMTP traffic. Leave this selected unless you want to refuse connections from servers that cannot authenticate ”in other words, enable anonymous access if you want your server to be able to receive e-mail from Internet SMTP servers. When this check box is selected, the Users button is disabled; this is sensible , because allowing anonymous access renders the whole idea of access controls moot.

• The Basic Authentication check box controls whether the SMTP server will allow basic, unencrypted authentication with the AUTH extension (part of the Simple Authentication and Security Layer [SASL] protocol, which you might remember from Chapter 2, Security Protocols and Algorithms ). Passing credentials over the Internet in cleartext is a really bad idea, so Exchange System Manager and Internet Services Manager warn you when you turn this option on. For additional safety, the Requires TLS Encryption check box allows you to force the use of SSL/TLS, thus encrypting communications between the client and server. When this check box is selected, no credentials are exchanged until the sender and your Exchange server have completed an SSL/TLS negotiation, begun with the STARTTLS verb. Microsoft Outlook Express and Eudora support SSL/TLS. Make sure the clients and servers you want to talk to support SSL/TLS or they will be denied permission to connect. (Note that using SSL/TLS will affect your servers performance by as much as 40 percent, depending on the number of simultaneous connections. However, the additional security might well be worth it for your applications.)

• The Default Domain text box lets you enter the DNS or NetBIOS name of an Active Directory domain. If the supplied authentication credentials don t include a domain, the credentials the sender provides are evaluated against this domain.

• The Integrated Windows Authentication check box enables the use of the standard Windows authentication methods discussed in Chapter 3, Windows and Exchange Security Architecture. In short, selecting this check box enables the use of NTLM or Kerberos as authentication methods. (AUTH NTLM and AUTH GSSAPI are the verbs to watch for in the SMTP stream.) When this check box is selected, users Windows credentials are automatically passed to the SMTP server. This option is quite useful for clients who are logged in with domain accounts when they re sending to your SMTP server, but it is less useful for those who aren t.

• The Users button brings up the standard Windows ACL editor dialog box (see Figure 8-5). Using this dialog box, you can grant or deny two new Exchange-specific permissions: Submit, which controls whether the selected users can pass a message to the virtual server for categorization and delivery; and Relay, which controls whether the selected users are allowed to relay through this virtual server. You can construct ACLs here just as you would with files, folders, or any other Windows object; the ACLs are stored in Active Directory under the ms-Exch-SubmitRelaySD attribute on the virtual server object.

  
  Figure 8-5: You can also assign permissions to control who can submit and relay mail through your servers.

  Note  

  Some firewalls and SMTP proxies block the STARTTLS verb. This blocking might occur for one of two reasons: the device might be configured to prevent mail encryption so that it can inspect the data going past for viruses or other bad content, or it might be configured not to allow anything other than the most basic set of SMTP commands. If you have TLS enabled and you find that some clients or servers cannot successfully send mail through your SMTP server, this is one place to look for the cause of the problem.

Remember that the Authentication dialog box just controls who can connect to your server in the first place. An authenticated (or anonymous) user who successfully connects can still be further restricted using the other connection control features.

Controlling Connections by IP Address

You can use the Connection button to specify which IP addresses your virtual server will or will not talk to. This is particularly useful for multihomed servers because you can bind different virtual servers to each of the IP addresses ”and it s even more valuable if your SMTP server happens to have one interface to the Internet and another to a private local area network (LAN). The Connection dialog box (shown in Figure 8-6) has two primary options: Only The List Below specifies that you want to allow connections from listed hosts and no one else, whereas All Except The List Below means you want to allow anyone except the listed hosts to connect. The Add and Remove buttons allow you to manage the contents of the Computers list. When you click Add, you ll get the oddly named Computer dialog box (shown in Figure 8-7), from which you can add a single IP address, a range of IP addresses ( expressed as an IP address plus a subnet mask), or a DNS domain. (The DNS Lookup button lets you quickly turn the DNS name into an IP address, for times when you don t have the IP address handy.) Note that turning on connection restrictions by DNS domain requires a reverse DNS lookup for every connection. On busy servers, that can reduce performance significantly.

Figure 8-6: Block or allow SMTP connections by specifying IP addresses in the Connection dialog box.

Figure 8-7: Use the Computer dialog box to specify IP addresses, ranges, or DNS domains that you want to block.

Note  

When you change the IP address restriction list, you must stop and restart the SMTP virtual server before the changes take effect. Don t forget to do this, or your restrictions will be ineffective .

Controlling Who Can Relay

The Relay button on the Access tab is what you use to specify which computers can relay through your SMTP server. The relay restrictions control which computers can use the RCPT TO verb with nonlocal recipients. Remember that the routing engine might still send an NDR after the SMTP server accepts it!

The Relay Restrictions dialog box (shown in Figure 8-8) works in much the same manner as the Connection dialog box: you choose whether the list in the Computers dialog box is a list of those who can relay or a list of those who cannot. The Add and Remove buttons allow you to manage the list. Clicking Add displays the same Computer dialog box you saw earlier in Figure 8-7, with exactly the same capabilities. The Allow All Computers Which Successfully Authenticate To Relay check box lets you override the restrictions so that any user who authenticates can relay ”a useful feature for mobile SMTP users. However, when that check box is selected, it disables the Users button.

Figure 8-8: The Relay Restrictions dialog box lets you specify who can and who cannot relay through your server.

Figure 8-8 shows the default Relay Restrictions dialog box, which allows relaying only for clients that authenticate, no matter what their IP address is. That behavior results from a combination of three things: the Allow All Computers check box is selected, the Only The List Below option is selected, and the Computers list is empty. If you want to completely prevent relaying, you could clear the Allow All Computers check box so that no one would be able to relay by default; you could then use the Users button (which is disabled when the Allow All Computers check box is selected) to specify which individual users or groups can or cannot relay. (Note that permissions added with the Users button aren t reflected in the Computers list.) You could also turn off all authentication methods in the virtual server s Authentication dialog box so that no one could authenticate. Conversely, if you wanted to allow certain hosts (say, those on an internal private IP network) to relay while preserving authenticated users relay privileges, you d need to add the internal IP range using the Add button.

Tip  

For maximum security, use two SMTP virtual servers. On the default server, allow only anonymous connections and do not allow relaying at all. On the additional virtual server, require authentication, enable SSL/TLS, and allow authenticated users to relay. This arrangement provides maximum separation of privileged and unprivileged access, and it allows you to maintain separate logs for the two virtual servers.

Configuring Relaying on SMTP Connectors

SMTP connectors are slightly different than SMTP virtual servers. The connector uses the virtual server as a transport mechanism, but it has additional features, including the ability to dequeue mail with ETRN or TURN, the ability to schedule when connections take place, and a facility for blocking messages over a certain size . These features make connectors particularly useful for sites connected over low-bandwidth or metered links. In addition, SMTP connectors allow you to force mail to particular domains through a connector that points to a specified smarthost . (For more details of how to set up and configure SMTP connectors, see Microsoft Knowledge Base articles 319426 and 319407.)

Caution  

If you allow relaying on an SMTP connector, its settings might override relay settings on the SMTP virtual server to which the connector points. Remember, when you create a new connector you have to specify the local bridgehead. The bridgehead you point the connector to will have its relaying restrictions, if any, on the default address space overridden by the connector. However, because the connector can point to individual address spaces, you can create multiple connectors with different address spaces ”each of which can have different relaying settings. Be careful, and make sure to test your relaying configuration before exposing a new connector or virtual server to the Internet.

When you create an SMTP connector, you specify which address spaces it should accept mail for. Unlike the SMTP virtual server, which accepts mail for all address spaces for which a recipient policy exists, the connector is perfectly capable of accepting mail for an external domain and forwarding it, either through the normal MX record process or by delivering it directly to another computer for further processing.

Creating a connector that allows relaying to specified domains is simple. The following steps walk you through the process of creating a connector that accepts inbound mail for delivery to Microsoft:

1. Launch Exchange System Manager, and navigate to the routing group container in which you want to create the connector (for example, First Administrative Group Routing Groups routingGroupName ).

2. Right-click the Connections folder, and choose the New SMTP Connector command.

3. On the General tab of the connector Properties dialog box, fill in the Name field. (Remember, SMTP connectors are unidirectional, so a name like Toledo “ Redmond makes clear what the connector is for.)

   • Use the two option buttons to specify whether you want to use DNS MX queries to find the other end of the connector, or whether you want to route all mail for addresses that match this connector s address space to a specified smarthost or smarthosts.

   • Use the Add button to select the local bridgeheads in the routing group that will host this connector. Remember, the SMTP virtual servers you select here will have their relaying settings overridden by the connector s settings.

4. Click the Address Space tab, and use the Add button to create an address space entry for the remote domain (in this case, *.microsoft.com). Use the Allow Messages To Be Relayed To These Domains option if you want to accept mail for those domains from the outside world (or your IMAP and POP clients that use this SMTP server to send their outgoing mail).

Accepting or Rejecting Messages on a Connector

One nifty Exchange Server 2003 feature is tucked away on the Delivery Restrictions tab of the SMTP Connector Properties dialog box. The controls in this dialog box (see Figure 8-9) let you specify which users can pass messages through the connector. By default, messages from all users are accepted. This is normally what you want; after all, the purpose of a connector is to connect! However, if you ve built connectors to control traffic flow to or from particular domains, you might want to allow only specific users to send messages over them; in addition, you might want to reject messages from a defined set of users. You can do either or both of these on the Delivery Restrictions tab.

 

Accepting or Rejecting Messages on a Connector

Figure 8-9: The Delivery Restrictions tab lets you control which users can use an SMTP connector.

You can also use the Content Restrictions tab to control message flow according to the priority, type (system or nonsystem), and size of a submitted message. This is a useful adjunct to other restrictions, but it s not necessarily a security measure. Remember that Exchange dynamically updates its routing tables whenever there s a topology change; the restrictions you put on a connector might be circumvented if a message is passed over another set of connectors.

 

Verifying Your Relaying Configuration

To test whether your machine is open for relaying, the best bet is to check it yourself. Internet relay testing services might actually report you to various spam block lists if they think you re an open relay. This threat is compounded by the fact that many poorly written relay testers flag Exchange Server 2003 as being an open relay even when it s not. This problem arises for efficiency reasons: if Exchange sees a recipient whose domain isn t specified (for example, RCPT TO: paulr), it doesn t immediately reject the message. Instead, it accepts it for delivery and adds the default SMTP domain; this allows it to generate an NDR later if the specified recipient doesn t exist. This behavior fools some relay checkers that expect to see an immediate 550 5.7.1 Relaying prohibited message, even though Exchange is following RFC 822 and is behaving in an acceptable way. (See Knowledge Base article 304897 for more information.)

Relay testing is simple if you understand the basics of the SMTP protocol. Each conversation has to specify the sender, the recipient, and the message data, in that order. By using the Windows Telnet client, you can easily pretend to be an SMTP sender who s trying to relay. (Of course, that s one of the reasons people turn on authentication and encryption for SMTP sessions: SMTP traffic is trivial to forge .) This testing works only if your SMTP server is set to allow anonymous connections.

Microsoft Knowledge Base article 153119 describes this process, but it s worth going over in more detail. Begin by opening a Telnet session on port 25 to your SMTP server, like this:

 telnet exchange.mycompany.com 25 

Your Exchange server responds with a banner. Notice that the banner begins with 220, which means that everything s fine. Every response you get from the SMTP server has a response code at the beginning. Over time, you ll learn to recognize them. The banner also tells you the DNS name of the server and the version number of its SMTP service:

 220 exchange.mycompany.com Microsoft ESMTP MAIL Service,   Version: 6.0.3790.0  ready at Wed, 08 Oct 2003 15:43:55 -0400 

Because the server s last response was a 220, you can now begin your conversation with the HELO verb, followed by the DNS name of your machine:

 HELO myworkstation.mycompany.com 

The SMTP server responds with a 250 message, signaling that it recognizes you:

 250 exchange.mycompany.com Hello myworkstation.mycompany.com 

Now the fun begins: you need to tell the server who you are. Type MAIL FROM: followed by your e-mail address. The server responds with another 250 message, indicating that the sender is okay. Next, you ll need to specify who the mail is going to, which you do by typing RCPT TO , followed by a nonlocal recipient address:

 RCPT TO:[e-mail] 

The server should immediately tell you that relaying is not allowed:

 550 5.7.1 Unable to relay for [e-mail] 

If instead you see the message has been accepted (250 2.1.5 [e-mail] in this example), you know your machine might still be capable of relaying. Go back and double-check your relaying configuration to ensure that it s correct.