SQL Server Magazine

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.

   Prev. page   [1] 2     next page