Exchange Server

Stop Spam From the Inside by Locking Down SMTP

Greg Taylor

 

At a Glance:

  • Why lock down SMTP services?
  • The differences between submitting and relaying mail
  • Configuring your SMTP Virtual Servers
  • Making sure the SMTP exceptions are secure

Exchange Server 2003

SMTP Virtual Servers

POP3 and IMAP4

It wasn’t that long ago when our only concern when talking about SMTP security was whether our servers were acting as an open relay. Microsoft Exchange, by default, stopped

allowing open relays after Exchange Server 5.5 and over time we all got to know how to check that we were not being inadvertently used by others to deliver their junk e-mail for them.

Sadly, those individuals who used someone else’s open relay to do their dirty work have discovered there are other ways of getting the same result, despite all those open relays being closed down. In this article I hope to show what they are trying to do and, more importantly, what you can do to stop it from happening.

But I Thought I Was Safe

Well, you probably are safe—from anonymous relaying, which is the most common form of attack—but what about authenticated relaying? Why would someone inside your company want to send spam, you might ask? I guess there are two answers to that question, but the answer you are probably most interested in is this: the users inside your company don’t know they are doing it! Viruses, trojans, and so on can all be used to send spam without the user’s knowledge. And all of these pests use the credentials of the logged in user or computer when talking to their local Exchange server. This is called an SMTP AUTH attack.

As far as Exchange is concerned, a user inside the organization is authorized to send mail to whomever they want. So Exchange takes that e-mail and sends it onwards without any question. When someone is using Outlook® that’s fine, but why would a user on the corporate LAN need to send e-mails destined for the outside world directly to Exchange by using SMTP? With few exceptions, they shouldn’t need to do that—so that’s what you want to prevent. In fact, I’m going to take you one step further than that and stop users on the corporate LAN from even submitting mail to an Exchange server by using SMTP. Users don’t need to be able to do that, so your best bet is to work on the principle of "if it isn’t needed, turn it off".

Just to avoid any misunderstandings down the line let’s agree on the difference between submitting mail and relaying mail. It’s really quite simple.

  • Submitting mail to Exchange means sending a mail to a recipient within the Exchange organization.
  • Relaying mail means trying to send a mail to a recipient who is outside the Exchange organization.

SMTP Virtual Servers

Exchange uses SMTP Virtual Servers to allow configuration of the various settings that can be used to control the service. In Exchange Server 2003, the properties for an SMTP Virtual Server are found in Exchange System Manager under the Server object, the Protocols container, and then under the SMTP node. Right-click the Default SMTP Virtual Server and choose Properties. The tab I’m going to be discussing in detail is called Access (see Figure 1).

Clicking the Authentication button displays the aptly named Authentication dialog box shown in Figure 2. The options available here specify the authentication methods that can be used to access the SMTP Virtual Server. For example, if Anonymous Access is checked any anonymous client can use SMTP to talk to your server. If Basic Authentication is enabled someone can send clear text credentials to authenticate. It’s as simple as that.

Figure 1 Access Settings

Figure 1** Access Settings **

Your first reaction when seeing the Integrated Windows Authentication checkbox ticked may be to remove it—why do you need that if Outlook doesn’t actually use SMTP when sending mail? You would be quite correct in your reasoning. However, Exchange does use Integrated Windows Authentication when talking to another Exchange server. So if you remove it, you will stop Exchange servers from being able to pass messages to each other. Exchange actually uses the ESMTP X-EXPS Kerberos authentication verb. X-EXPS is proprietary to Exchange, though it is similar to AUTH. There is no maximum size limit for the data chunks or the number of data chunks exchanged. For more information about this issue, see Knowledge Base article 812455, "Definitions of Verbs That Are Used Between 2 Exchange Servers".

Figure 2 Authentication Options

Figure 2** Authentication Options **

The Relay button displays the Relay Restrictions dialog box shown in Figure 3. The dialog box shown here illustrates the default relaying configurations: no computers are allowed to relay unless they are authenticated. Now in addition to this being a potential security risk as described earlier, this is often the source of a common misconception. Some administrators believe that this checkbox is needed to allow Exchange servers to send mail to each other. This is not true, as previously explained. Exchange servers do not relay mail to each other; they submit mail to each other, whether it is for forwarding or for local delivery to a mailbox on the server.

Figure 3 Relay Restrictions

Figure 3** Relay Restrictions **

One final thing to look at on the properties of the SMTP Virtual Server is the Users button, which is visible at the bottom of the Authentication settings dialog box, and which only becomes available in the Relay Restrictions dialog box when you remove the check next to Allow all computers which successfully authenticate to relay, regardless of the previous list.

This is interesting for several reasons. First, this button does not become available in Exchange Server 2003 RTM (pre-Service Pack 1) without first unchecking the Anonymous Authentication box. It makes sense, really. If you allow anonymous connections, what effect could the submit access control list (ACL) have? Once you disable anonymous access, however, you can choose at a user or group level who is able to submit and relay through that SMTP Virtual Server.

There is a trick that allows you to remove authenticated submission and relaying, and yet still allow Exchange servers to communicate with each other. To do this, remove the default Authenticated Users group from the Permissions for Submit and Relay dialog box, leaving the Group or user names box empty (see Figure 4), and then click OK. Now Integrated Authentication access is allowed on the SMTP Virtual Server, but no user or group can actually use it. Only Exchange servers within the same organization can use it to communicate with each other.

Figure 4 Users Permissions Removed

Figure 4** Users Permissions Removed **

As you can see, there are a variety of settings available in these dialog boxes and some of them can have quite dramatic effects on mail flow if not set correctly, so let’s look at the role a server plays within an organization and what settings that role dictates. These settings are summarized in Figure 5.

Figure 5 Virtual Server Settings by Roll

  Authentication Settings Relay Restrictions Settings
Server Role Anonymous Access Basic Authentication Integrated Authentication Remove all entries from ACL under the Users button Select which computer may relay through this virtual server Allow all computers that successfully authenticate to relay
SMTP Gateway Enabled Only if non-Windows clients need to relay Enabled Yes (unless POP3/IMAP4 clients need to relay) Only the list below Unchecked (unless non-authenticating systems need to relay)
Mailbox/Public Folder Disabled Disabled Enabled Yes Only the list below Unchecked
Front-End Disabled Disabled Only if SMTP is required Yes Only the list below Unchecked
All-in-One Enabled Disabled Enabled Yes Only the list below Unchecked

SMTP Gateway An SMTP Gateway server talks directly to the Internet (or sometimes indirectly through a smart host or ISA server). Mail comes in to this server anonymously—that’s the basis of general SMTP mail flow across the Internet. This server therefore needs anonymous access enabled to the SMTP Virtual Server. No one should need to relay through this server unless you have applications or devices which need to send mail outside the organization—in which case you may need to set this server to allow relaying in some way.

Mailbox Server A dedicated mailbox server does not talk directly to the Internet and should not be the target of any SMTP submissions, whether they are for recipients inside or outside the Organization. This exact same configuration would apply for a public folder server.

Front-End Server A front-end server, dedicated just to Outlook Web Access (OWA) and perhaps other services such as RPC/HTTPS or Exchange ActiveSync, does not even need the SMTP or Information Store services running. For details, check out the Security Hardening Guide for Exchange Server 2003 at the TechNet Exchange Server 2003 Technical Documentation Library. If, on the other hand, you are using your front-end servers to route SMTP you will need all services running and you should therefore treat this server as you would an SMTP Gateway.

All-in-One Server If you have a single server in your organization or a small number of servers, and all of them can accept mail from the Internet, then they all need to allow anonymous mail. They don’t need to allow authenticated submission or relaying, so turn that off.

Exceptions to the Rule

There are always going to be exceptions to any rule and I have already mentioned one: a custom application or device that needs to be able to send e-mail. Another might be the need to support remote workers who use POP3 or IMAP4 to retrieve mail, but need to be able to use your SMTP service to send mail. How do you configure things for them yet keep the overall setup secure?

There are several ways to deal with these issues and they depend upon the configuration of the sending machine, application, device, or user and whether the mail is destined for a recipient inside or outside your organization. Let’s look at the various combinations you might see and describe how each might be tackled.

One thing to note is that if you are to relax security to allow these scenarios, consider making those changes only on your SMTP Gateway server(s). Chances are that you already have anonymous access allowed to receive Internet mail, and some of these workarounds need that enabled, so use the SMTP Gateway and don’t reduce security of your mailbox servers, even if the users or applications are physically closer to them. SMTP is pretty good at slow links, so let it do its stuff.

Remote Worker Using POP3 or IMAP4 First, I would suggest trying to move away from POP3 and IMAP4. Why not use Outlook 2003 and RPC/HTTPS? Why not OWA? Enabling POP3 and IMAP4 for this type of remote worker reduces your overall level of security considerably. Still, if you really do need to support it you will need to either allow relaying on the SMTP Gateway or set up a separate externally facing POP3/IMAP server (see Figure 6) and then specify, by group preferably, which users are allowed to submit and relay mail this way. Even though these are POP3 and IMAP4 clients, don’t check Basic Authentication. Just leave Integrated Windows Authentication checked and your clients will try to negotiate the strongest method they can for passing credentials, assuming that your clients are using Windows.

Figure 6 Supporting POP3/IMAP4 Users

Figure 6** Supporting POP3/IMAP4 Users **

Applications that Send Mail to Internal Mailboxes You have an application or device that needs to send mail to a recipient inside your Exchange organization. This one is pretty simple: give the application the IP address or name of the SMTP Gateway server. As the recipient of the mail is internal, Exchange will simply accept the mail as it would any other mail for that user coming from the Internet and will deliver it to the user’s mailbox.

Applications that Send Mail to External Recipients The approach you use will have to depend upon the application or device that wants to send the mail and what authentication methods it can support. Can that application or device authenticate in some way with the Exchange server when it tries to send the e-mail? If so, you can allow that user (or again, best practice would always suggest a group is used) permission to submit and relay mail by using the ACL on the SMTP Virtual Server. Make sure you target the application at the SMTP Gateway server as it is the only server configured to allow anonymous access. You may need to enable Basic Authentication as well.

But what if the application or device cannot use any form of outbound credentials? What if the device is a router or storage hardware and wants to send a status e-mail to the vendor’s support department? This can still be done. The device needs to use the SMTP Gateway server as its SMTP server, and then the IP address of the device needs to be added to the list of computers that are allowed to relay (see Figure 7).

Figure 7 Allowing Relay by IP Address

Figure 7** Allowing Relay by IP Address **

Conclusion

Exchange Server 2003 provides a high level of security out of the box, but there are ways to go even further and lock down SMTP to reduce the risk of unwanted mail being relayed from inside your network. You can prevent users and applications inside the network from mailing each other using anything other than Outlook, though you can also configure the system to allow applications and devices the freedom to communicate through your Exchange server.

Even if a computer within your network is compromised, you can keep it from taking advantage of your SMTP. That’s one less risk you need to stay awake worrying about.

Greg Taylor is a Senior Consultant for Microsoft in the UK. He has been working with Exchange for seven years.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.