Top 5 Exchange Server 2007 Security Best Practices

By Devin L. Ganger , Exchange MVP

See other Security MVP Article of the Month columns.

There is no doubt about it: Microsoft Exchange Server 2007 is a big win for the security-conscious messaging administrator. Exchange Server 2007 boasts a number of out-of-the-box features and configuration changes that greatly reduce the amount of security worries you need to juggle – features such as the new role-based modular architecture, the simplified and granular administrative delegation model, and the default use of high-grade encryption for every connection between Exchange servers in an organization.

Many of the new features and much of the new functionality are designed to make it even easier for your users to get to their Exchange Server mailboxes and data no matter where they are – at their desks, on the road with a laptop, or even using mobile devices such as Windows Mobile powered Pocket PCs or smartphones. As you begin testing and deploying Exchange Server 2007 in your organization, you’ll find that securely managing this kind of “anywhere access” is easier than ever before.

No matter how good the bits are straight from the DVD, though, Exchange Server 2007 is software; no installed software can ever be completely secure just by installing it, then forgetting about it. To get the best security value out of Exchange Server 2007, here are five best practices you can follow.

Number 5: Use the Client Submission Port

When they designed the Exchange Server 2007 transport servers (the Hub Transport and Edge Transport roles), the members of the Exchange Server product team made a great decision that makes it easier than ever to quickly and securely configure Simple Mail Transfer Protocol (SMTP) connections: they separated the receive functionality (the SMTP server role) from the send functionality (the SMTP client role). As a result, you now have Receive Connectors and Send Connectors, allowing you to more easily break down SMTP traffic between the server role and the client role as shown in Figure 1.

Figure 1: Beginning a client-server SMTP session

This split permits Exchange Server 2007 to offer out-of-the-box support for the Client Submission Port de facto Internet standard. Many ISPs and networks block outgoing TCP 25 connections to reduce the amount of spam coming from their networks and force outgoing messages through their filtering. This can be a real bother for users who connect to different networks; they may have to reset their application configuration depending on the network they’re currently connected to.

The Client Submission Port standard proposes a solution for this problem by using two separate SMTP server ports: the default TCP port 25 and an additional TCP port 587. In Exchange Server 2007, these are implemented as two receive connectors on Hub Transport servers:

• The Default Receive Connector on TCP port 25 (the standard SMTP port) is intended to receive traffic from other SMTP servers, which is necessary to receive general Internet e-mail. Although DNS MX records let you specify which servers are intended to receive incoming mail from untrusted sources, there is no provision for designating an alternate TCP port number -- these connections all come in on TCP port 25.

• The Client Receive Connector on TCP port 587 is intended to support the use of SMTP mail clients such as Windows Live Mail Desktop, Office Outlook Express, or other applications your users may have deployed. Because these submissions are coming from your users, these connections should be authenticated so that the messages can be treated with a higher level of trust.

Legacy Exchange servers and Exchange Server 2007 transport servers in your organization use port 25 for SMTP communications with each other. If a Hub Transport server is intended to receive incoming messages from the Internet, its Default Receive Connector should allow anonymous connections. By default, this connector requires authentication; Exchange Server assumes you are using an Edge Transport server as your external gateway.

The Client Receive Connector gives you an alternative to requiring authenticated SMTP on your main external mail gateway, especially if that gateway is a third-party appliance. Using this port gives your users the ability to submit messages to your servers even when they’re on the road, without needing to change their configurations.

I should point out that if your users are using Outlook Anywhere with Office Outlook 2007, RPC over HTTPS with Outlook 2003, or WebDAV connection with Microsoft Entourage 2004 or 2008, they don’t have to worry about this problem (and neither do you). Likewise, mobile devices that use the Exchange ActiveSync (EAS) protocol won’t be affected by this.

If you’re curious about the Client Submission Port, you can find out more details (and benefits) from a blog post I wrote, “TCP Port 25 Considered Harmful?”

Number 4: Disable HTTP connections

This advice may seem a bit contrary to the goal of “anywhere access.” After all, most of the protocols that permit your users to get their Exchange Server mailbox data from anywhere depend on the HyperText Transfer Protocol (HTTP):

• Outlook Anywhere for Outlook 2007, formerly known as RPC over HTTP in its previous incarnation with Outlook 2003, uses MAPI RPCs over HTTP.

• Windows Mobile devices use EAS, which is a Web-based mailbox synchronization protocol based on HTTP. EAS is licensed to a growing number of non-Windows Mobile powered devices.

• Mac computers running Microsoft Entourage use the Web Document Authoring and Versioning (WebDAV) protocol, which is again based on HTTP.

Obviously, I’m not telling you to disable all HTTP-based protocols. Basic HTTP is a security risk, though, because it transmits all data in cleartext; anyone who is snooping the connection can listen to every bit of data and reconstruct your users’ messages. As a result, anytime you’re deploying HTTP-based protocols, you should always enable encryption through SSL (or its successor protocol TLS). This helps protect you and your users when they connect, especially when using Basic authentication (as is common for many mobile devices).

It is surprising how many people know that they need to use SSL and enable it, then proceed to merrily publish both the secure and insecure versions of the protocol to the outside world. One common reason for doing it is troubleshooting: it can be much easier to troubleshoot unencrypted connections. However, once you’ve performed your initial testing and verified your publishing configuration, you should disable plain HTTP.

Number 3: Don’t use default certificates on Internet-facing server roles

One of the biggest sources of objections to using SSL and TLS is the requirement for X.509 digital certificates. Some common objections I’ve heard include:

• “Buying commercial certificates costs too much.”

• “Deploying a certificate PKI is too complicated.”

• “Certificates make it too hard to troubleshoot.”

The Exchange Server product team has heard these objections (and more) over the years and finally addressed it in Exchange Server 2007. When you set up each Exchange Server 2007 server, the installer will generate a self-signed certificate that the server uses to secure communications with other Exchange Server 2007 servers and Office Outlook 2007 clients. If you have a pre-existing certificate on the machine (maybe you already have a PKI deployed, such as Windows Certificate Services), you can specify this certificate during Setup. Exchange Server 2007 will happily use that certificate instead.

These self-signed certificates are a great security step forward for organizations that don’t have anything deployed; just by upgrading, they now get the benefit of secure transport communications without performing any extra work. They’ll even work as you publish services out to the Internet, after a fashion; Office Outlook clients will give certificate warnings, which will be worrisome and annoying to your users, while other clients (including Windows Mobile devices) won’t be able to use these self-signed certificates.

As a result, you should, at a minimum, hedge your bets. By that I mean even if you make use of the self-signed certificates inside of your organization, purchase commercial certificates from a reputable certificate authority for use with your SMTP and HTTP servers – that is, any host (whether a client or server) that will be initiating or receiving connections from the Internet. Here are some issues you should watch out for:

• You may need to publish a variety of hostnames, such as for OWA, the Autodiscover service, and your edge mail gateways. Typically, with SSL this means one certificate per hostname -- which can get expensive fast. You may want to use a wildcard certificate to reduce the cost and configuration complexity. Be aware, however, that mobile devices running Windows Mobile 5.0 and previous versions do not support wildcard certificates. Your users need to be running Window Mobile 6 or later to be compatible.

• Another new option is the ability to specify multiple hostnames on one certificate This type of certificate uses the Subject Alternate Name (SAN) X.509 field and is commonly known as a SAN certificate. These certificates are typically more expensive and are slightly harder to deploy. They also may cause additional complications if you are using ISA Server to publish your services. ISA Server 2004 does not support the use of SAN certificates; you’ll need to upgrade to ISA Server 2006.

• Be sure to test your mobile devices and computer configurations with the certificates provided by a commercial certificate authority. Not all devices have the necessary root certificates loaded. This is also a problem if you’re deploying certificates from an internal PKI. The process of pushing out root certificates to all of your users can be more complicated than you might expect, especially if you don’t restrict supported devices to a list of approved devices.

For additional information on deploying commercial certificates, you should read the Exchange 2007 Autodiscover Service whitepaper and the Managing SSL for a Client Access Server documentation topic.

Number 2: Use the Security Configuration Wizard

By now, we’ve all heard the security mantra “defense in depth” often enough that it’s actually sinking in. We all know that a strong defense strategy means not only using secure features and technologies, but also using firewalls to limit access between your servers and hosts on other networks. As a final layer of defense, you also need to harden your Exchange servers; this means shutting down unnecessary services and reducing the potential vectors for attackers to successfully exploit, even if they get through the other defenses. As an example, Exchange servers don’t need to act as file servers in most circumstances, so you don’t need to keep the Windows File and Print Services bindings active on your network interfaces.

Over the years, a number of people and companies, including Microsoft, have developed hardening checklists and procedures for each version of Exchange Server. With Exchange Server 2007, though, Microsoft makes it a lot easier to harden your servers by using the Security Configuration Wizard (SCW). The SCW, an optional component first introduced in Windows Server 2003 Service Pack 1, uses a library of XML files to help determine which services, settings, and ports can be safely shut down without affecting the applications the server is running.

Once you have the SCW component installed, you need to tell it about Exchange Server 2007; by default, it only knows about Exchange Server 2003. To do this, you need to register the Exchange 2007 SCW extensions, which are two XML files that provide the information the SCW needs to successfully harden Exchange Server 2007 servers. These files are included with Exchange Server 2007; which ones you use are determined by the server roles installed on the server, as shown in Table 1.

Table 1: Exchange Server 2007 SCW extensions files

Once you’ve gotten the extensions installed, you can use the SCW to harden your Exchange Server 2007 servers as shown in Figure 2.

Figure 2: Hardening an Exchange Server 2007 mailbox server with the SCW

Number 1: Place your Exchange Servers correctly

With Exchange Server 2003 and previous versions, you had a lot of network design issues that you had to consider when you were securing your Exchange deployment. The question that generated some of the most discussion, though, is where to place front-end servers and external bridgehead servers. The two main options -- the interior protected network or a perimeter network -- were both supported by Microsoft, but they offered different tradeoffs:

• Placing these servers in the interior network was the recommended option, but many people don’t like it because they dislike running the risk of letting connections from the Internet reach through their defensive layers without some sort of filtering. In this deployment, the best practice was to use some sort of proxy server such as Microsoft Internet Security and Acceleration (ISA) Server, in order to filter the connections and perform pre-authentication.

• Placing these servers in a perimeter network, on the other hand, weakens the value of the perimeter network. Exchange Servers must be members of Active Directory, so placing them in a perimeter network involves opening a large number of ports and connections to critical infrastructure servers. This option was the recommended practice before ISA Server was released.

With Exchange Server 2007 multiple role architecture, this question becomes simple to answer as shown in Figure 3. The only Exchange Server 2007 role that is supported in a perimeter network is Edge Transport; all four other roles are only supported in your interior protected network.

Figure 3: Placing Exchange Server 2007 roles in your network

This seems to be one of the hardest conceptual changes for many experienced Exchange Server administrators to make. Many people still think they need to deploy their Client Access or Hub Transport servers in a perimeter network. Doing so lessens the value of many of the out-of-the-box security measures in Exchange Server 2007, drastically complicates your firewall configurations, and exposes your Active Directory domain controllers to potential attacks. If there is a need to limit and filter incoming connections from untrusted sources, use a properly designed application proxy server such as ISA Server, deployed in the perimeter network. Your firewall administrators will thank you.