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.
Previous
Register
