Securing Microsoft Exchange Server 2007

Executive Summary: Securing Microsoft Exchange Server 2007 includes everything from creating a high-level architectural design to tweaking dozens of obscure settings deep within the product. Start by considering fundamental practices such as limiting yourself to one version of Exchange and using the different Exchange server roles wisely. You'll greatly increase the chances that the security settings you implement later on will be effective.

Exchange Server 2007 is designed to be much more secure than its predecessors, but it would take a thick book to tell you all you need to know about Exchange 2007 security. After all, securing Exchange 2007 includes everything from creating a high-level architectural design to tweaking dozens of obscure settings deep within the product.

My personal philosophy has always been that security must be applied in layers. Tweaking a bunch of security settings won’t do you much good if you have gaping security holes throughout your Exchange organization. That being the case, I’ll focus this article on designing a secure Exchange Server organization, discussing fundamental, big-picture practices such as limiting yourself to one version of Exchange and using the different Exchange roles wisely. If you start with a secure design, you greatly increase the chances that the security settings you implement later on will be effective.

Harden Windows and Use Firewalls
The majority of the security steps that I talk about in this article have to do with the design of your Exchange organization rather than the deployment process. I want to quickly mention, though, that when it does come time to deploy Exchange, one of the most important things to do from a security standpoint is to harden Windows before you ever even install Exchange.

Exchange Server is completely dependent upon the Windows OS. If your Windows implementation has weak security, then your Exchange implementation will also have weak security. Therefore, it’s extremely important that you remove all unnecessary Windows components and services, install all the latest Windows patches, and follow the various security best practices for Windows. You can get more specific information from the Windows Server 2003 Security Guide, which you can download at www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx You can also use the Security Configuration Wizard to help you to harden your servers and reduce their potential attack surface. You can download the Security Configuration Wizard at www.microsoft.com/downloads/details.aspx?familyid=903fd496-9eb9-4a45-aa00-3f2f20fd6171&displaylang=en.

Furthermore, it’s extremely important that your organization use a solid firewall configuration. My personal recommendation is to take a layered approach to firewalls. Your network perimeter should be protected by a firewall appliance, but I also recommend placing a Microsoft ISA Server system just inside your perimeter network. ISA Server was developed with Exchange Server in mind and makes an effective application firewall. Even with ISA Server in place, though, you should use the Windows firewall on each of your servers as a way of preventing attacks that may occur from within your organization.

Use Only 1 Exchange Version
In my opinion, one important aspect of developing a secure Exchange Server organization is maintaining strict control over both Exchange and Windows server versions. For example, if you’re getting ready to move to Exchange Server 2007, then I think it’s better from a security (and, certainly, management) standpoint to deploy Exchange 2007 on all your Exchange servers than to have a mixture of Exchange 2007 and Exchange Server 2003.

A lot of you are probably having a fit after reading that last statement. After all, Microsoft fully supports coexistence between Exchange 2007, Exchange 2003, and Exchange 2000 Server. Hear me out, though.

One reason why I recommend trying to limit your organization to one Exchange version is that by doing so, you reduce management complexity. For example, Exchange 2003 requires the use of sites, routing groups, and administrative groups. These features were removed from Exchange 2007, but Exchange 2007 can emulate these features to remain backward-compatible with the earlier version. By removing Exchange 2003 from your organization, you eliminate Exchange Server 2007’s need to emulate these features, thus reducing the complexity of the code that’s running.

My general rule of thumb when designing an Exchange Server organization is that you should reduce complexity anywhere possible. Doing so often improves security and makes troubleshooting any problems easier.

Another reason why I believe that staying with one Exchange version is important is that it helps eliminate the “what if” factor. Imagine, for example, that you’re running Exchange 2007 and Exchange 2003. Now suppose that someone discovers a huge security flaw related to the way Exchange 2007 interacts with the server’s transport stack. (This isn’t a real problem, it’s just an example.)

In a situation like this, it’s appropriate to wonder whether the vulnerability is unique to Exchange 2007 or also exists in Exchange 2003. If all your Exchange servers were running Exchange 2007, you simply focus your attention on patching the known bug, rather than trying to determine whether another version of Exchange has a similar bug.

Put Only 1 Exchange Server Role on Each Server
The concept of server roles isn’t new to Exchange 2007, but this version takes the role concept much further than Exchange 2003 does. The only roles that formally exist in Exchange 2003 are those of front-end and back-end Microsoft Outlook Web Access (OWA) servers. Many administrators “define” their own Exchange 2003 roles, such as mailbox servers and public folder servers. In fact, Microsoft introduced other roles in the Microsoft Exchange Server 2003 Security Hardening Guide (www.microsoft.com/downloads/details.aspx?familyid=6A80711F-E5C9-4AEF-9A44-504DB09B9065&displaylang=en) but didn’t implement them in Exchange 2003 itself.

Exchange 2007 has five server roles and requires you to select the ones that you want to use during the initial Exchange installation. Of course, you also have the option of adding and removing server roles as your needs change.

The five roles are Mailbox, Client Access, Hub Transport, Edge Transport, and Unified Messaging. A single server can host multiple roles. The only roles that can’t work with other roles are the Edge Transport role, and the Mailbox role if the server is clustered. I discuss the Edge Transport server role in more detail later. Right now, though, I want to focus attention on the other four roles and how to design a secure Exchange environment with these roles in mind.

The Edge Transport role aside, a single Exchange server can run any combination of the various server roles. In fact, if you aren’t using the Edge Transport role, it’s possible to have one Exchange 2007 box that runs all the Exchange server roles simultaneously. However, for both security and performance reasons, I recommend that each Exchange server host only one role.

Servers running the Mailbox role host Exchange mailbox and/or public folder databases. It’s common practice to dedicate one or more servers to running the Mailbox server role, but the reason is typically related more to performance than security. Exchange databases tend to be resource hogs, so a dedicated server makes sense in many situations.

If you must consolidate server roles, then I recommend running the Mailbox role and the Hub Transport role on the same box (assuming that your hardware is up to the job). These two roles present the least chance of causing a security problem when run together.

Hub Transport servers are responsible for all internal mail flow, routing messages and applying filtering rules to them. Because this role and the Mailbox role both sit on the internal network, the security risks associated with running these two roles on the same box are minimal.

The Client Access role should always run on a dedicated server. This role is the Exchange 2007 equivalent of an Exchange 2003 front-end OWA server, meaning that it receives requests from the Internet and forwards them to a Mailbox server. Obviously, you should have a firewall sitting in front of the Client Access server filtering out everything except HTTP and HTTP Secure (HTTPS) traffic on ports 80 and 443. Even so, the Client Access role does receive traffic from the Internet, and it’s best to not have the Client Access server hosting other roles that could potentially be exploited.

The Unified Messaging role is completely new to Exchange 2007. In case you’re not familiar with unified messaging, it’s a new technology that allows voice messages and faxes to be received and stored alongside email messages. Unified Messaging servers provide a new type of interface called Outlook Voice Access (OVA), which lets users interact with the Exchange organization by using their voice or touch tones via a telephone.

In my opinion, OVA doesn’t pose nearly the security risks that OWA does because OVA doesn’t expose Unified Messaging servers to the Internet, and Unified Messaging users don’t use a computer to connect to the servers. However, OVA does expose Unified Messaging servers to the Public Switched Telephone Network (PSTN), which arguably has worse security and more connected devices than the Internet. Thus, I recommend isolating Unified Messaging servers from the rest of the Exchange server organization with a firewall. In addition, Unified Messaging servers are extremely resource intensive and that condition alone often justifies using a dedicated server.

Employ an Edge Transport Server
The Edge Transport server role is new in Exchange 2007. I want to talk about this role separately because its entire purpose is to help secure the Exchange organization. I recommend that every Exchange environment uses an Edge Transport server as an important part of its security plan.

Using an Edge Transport server role is like bringing hosted filtering in house. If you aren’t familiar with hosted filtering, I discuss it next. An Edge Transport server sits behind the corporate firewall but is isolated from the rest of your Exchange server organization, usually on a separate network segment. The Edge Transport server filters messages before they enter your primary Exchange organization to get rid of viruses and spam, thus helping to lighten the workload of your Mailbox servers and Hub Transport server.

Having an Exchange server that’s dedicated to the task of removing viruses and spam before messages pass through to your internal network probably sounds like a good idea, but you might be apprehensive to deploy an Exchange server, with its dependency on Active Directory (AD), on the edge of your network. Earlier I mentioned that the Edge Transport role can’t coexist on a system with any other Exchange role. This is because Microsoft designed Exchange 2007 so that servers running the Edge Transport role don’t need AD access (at least not directly).

To avoid exposing AD to the outside world, an Edge Transport server relies on AD Application Mode (ADAM) instead. ADAM is an AD partition that stores data related to a specific application rather than storing a copy of the entire AD database. When you install the Edge Transport role, Exchange creates an ADAM database on the Edge Transport server.A minimal amount of information is then pushed from AD to the ADAM database to give the Edge Transport server the configuration information it needs, without exposing all of AD in the process.

Microsoft even designed the Edge Transport replication process to prevent exposure. The Edge Transport server never contacts the rest of the Exchange organization. Instead, the setup process creates a special XML file, called an edge subscription file, on the Edge Transport server. The edge subscription file tells your Exchange organization to replicate recipient and configuration information from AD to the ADAM partition on the Edge Transport server. The administrator copies this file to the Hub Transport server and then manually removes it from the Edge Transport server so that a hacker can’t use this file to exploit the replication process.

Given its role within the organization, an Edge Transport server is designed to be secure by default. As such, there isn’t anything special that you have to do to secure an Edge Transport server aside from making sure that Windows is installed securely, removing the edge subscription file, and following routine best practices that are common to all Exchange servers.

Choose Hosted Filtering
I’m a big believer in hosted filtering, in which a company such as an ISP filters out viruses and spam before they ever reach your Exchange organization. When hosted filtering is in use, the MX record for your domain doesn’t point to your mail server but rather to a designated IP address that belongs on the server that’s filtering content. This means that email doesn’t come directly to your organization but flows to the filtering company first. The filtering company scans for and removes viruses and spam and then forwards legitimate messages to your Exchange organization.

Hosted filtering offers at least three benefits. First, email viruses are eradicated by the filtering server and never reach your organization. I still recommend running antivirus software on your Exchange servers and email client machines, though. You never know when a virus might slip through the hosting company’s filter, and having your own antivirus software is a good second line of defense.

The second advantage of hosted filtering is that it helps to conserve network bandwidth. It’s probably safe to say that in most organizations, spam accounts for 60 percent to 90 percent of the total inbound email. If you can filter out most spam before it reaches your organization, you could end up saving a significant amount of Internet bandwidth just because your Exchange servers don’t have to download all that spam. Not only does blocking spam reduce Internet bandwidth consumption, but it also helps to conserve memory, CPU, and disk resources on your mail servers.

The third major benefit of hosted filtering is that it obscures your mail server’s IP address from the outside world. The DNS record that would normally point to your mail server now points to a filtering server that’s part of another company’s network. A hacker who attacks your mail server might not realize that you use hosted filtering and might directly attack the filtering company rather than you. A more sophisticated hacker might be able to determine your mail server’s real IP address, but locating it would be more difficult than it would be if hosted filtering weren’t in use.

This article just barely scratches the surface of what you need to know about Exchange security. Even so, good security starts with a secure design, and I’ve talked about some things that you can do to design your Exchange organization with security in mind.