SolutionBase: Developing a secure Exchange 2003 organization

E-mail is one of the most important functions on a network. If your Exchange server isn't secure, your organization isn't secure. These tips can help you beef up Exchange 2003 security.

When it comes to network security, perhaps no one component is as difficult (or as important) to secure as your Exchange Servers. It isn't so much that Exchange is inherently insecure, it's that Exchange is a very popular target for attacks. Exchange Servers are frequent targets of Web server hacks (OWA is a Web site after all), and denial of service attacks. Exchange Servers are also a favorite target of spammers who relay SPAM through another organization's mail servers to hide its true origin. Finally, your mail servers act as the entry point for E-mail viruses, and malicious HTML code that's embedded within SPAM messages. As you can see, it's extremely important that you harden your Exchange organization so that you won't be as vulnerable to these threats.

Front end/back end configuration issues

Before I get started, I want to point out that by far the biggest thing that you can do to make your Exchange organization more secure is to deploy Exchange in a front end/back end configuration (assuming that your organization uses OWA). Implementing a front end/back end configuration greatly reduces the attack surface that is exposed to the Internet. The front end server works solely as an OWA server and contains no data. All mailboxes and public folders are stored securely on a back end server.

Before I move on, I want to throw in my two cents worth about one particular front end/back end configuration related issue. The generally accepted way of implementing a front end/backend configuration involves placing an ISA Server in front of the front end server. The idea is that clients never interact directly with the front end server. Instead, clients communicate with the ISA Server and the ISA Server filters out undesirable requests. It then acts as a proxy by making requests of the front end server on behalf of the client.

The reason why this is a debated topic is that ISA Server is a software based firewall sitting on top of a Windows operating system. Some people feel that it is therefore incapable of performing securely in this capacity. My take on this issue is that ISA Server should be considered an essential part of a front end/back end configuration.

ISA Server is not a generic firewall. It was developed by Microsoft with Exchange in mind. It contains lots of Exchange specific filtering rules that will help to keep your Exchange Server secure. At the same time though, I believe that the fact that ISA Server rides on top of a Windows operating system does pose a security threat. In my opinion, the best way to counter this threat is to place a hardware-based firewall at your network's perimeter, and then have your hardware firewall forward the necessary traffic types to an ISA Server located behind it.

Protecting Exchange on all fronts

One of the biggest problems with designing a secure Exchange Server deployment is that even if you use a front end/backend configuration, Exchange Server has a huge attack surface. Sure, there is the Exchange Server application itself, but Exchange rides on top of Windows Server. There's no way that you can secure Exchange without securing the underlying Windows operating system.

That's only half of Exchange's attack surface though. The other half has to do with the clients who connect to Exchange. Clients typically use Microsoft Outlook or Outlook Web Access. In either case, there is typically also an underlying Windows operating system.

As you can see, if you want to protect an Exchange organization, you will have to secure Exchange itself, the underlying Windows Server, the operating system on the client machines, and the mail clients themselves (Outlook). The first step in doing this is to verify that the machines are always fully patched and that the necessary malware protection is in place.

I recommend deploying the Windows Server Update Service (WSUS) within your organization. WSUS is similar to Microsoft's previous patch management utility, SUS. The biggest difference is that SUS only patched the Windows operating system. WSUS patches the Windows operating system, but also patches Exchange Server, Microsoft Office (which includes Outlook), and a variety of other Microsoft Products. You can download WSUS for free from the Microsoft Web site.

WSUS will keep all of your Exchange organization's major components up to date, except for ISA Server. Microsoft plans on eventually providing patch management for all of its products through WSUS, so it should only be a matter of time before you can use WSUS to keep ISA Server up to date.

Applying patches as they become available will go a long way toward providing you with a secure Exchange organization. However, there are several other things that you must plan for as you design your Exchange organization. One threat that you absolutely must protect your Exchange organization against is viruses. Today, most viruses spread through E-mail, and most E-mail viruses are designed to exploit weaknesses in Exchange Server and / or Outlook.

In order to adequately protect your organization against viruses, you must install anti-virus protection at three different levels. First, you must install anti-virus software on each of your network's workstations. Being that our purpose is to guard against Exchange related security risks, you must make sure that the software that you choose to use integrates into Microsoft Outlook. Any anti-virus software will protect the workstation at the file system level. Outlook integration allows the software to scan messages that show up in the user's inbox and remove viral attachments before the user ever has a chance to open the message.

The next place that you need to install antivirus software is at the server level. Server level anti-virus software is basically just designed to protect the server's file system against viruses. If you are installing anti-virus software on an Exchange Server, then you may need to exclude the M: drive from being scanned. Exchange 2000 mapped the M: drive to the server's information store. If an anti-virus application attempts to scan this drive in the same way that it would scan another hard drive then the Exchange databases could become corrupt. Exchange Server 2003 does not use the M: drive mapping by default.

The last place that you need to implement anti-virus protection is at the Exchange level. An Exchange-aware anti-virus application will scan all inbound and outbound messages for viruses. If someone sends an infected message to one of your users, the Exchange level anti-virus software will clean the infection prior to the message being placed into the user's inbox.

A lot of people have asked me why Exchange level anti-virus software is even necessary being that the workstation level software scans messages prior to the user opening them. There are a few different reasons why Exchange level protection is important. One of the main reasons for doing so is that having anti-virus protection at the Exchange level and at the workstation level gives you two different lines of defense. That way you aren't just relying on one application to protect your mailboxes.

Some companies will even use different anti-virus products at the Exchange level and at the workstation level. The idea is that if a new virus comes out and someone sends a copy of it to one of your users, there may or may not be a signature for the new virus in your anti-virus software's database. If you are using two different products though, then you have doubled your chances of having the anti-virus signature and stopping the virus before it can do any damage. For example, if you are running Norton at the Exchange level, and Trend Micro's PC-cillin at the workstation level, then there's a pretty good chance that one of the two applications is going to catch a virus before a user can open a message and activate it.

Another reason why it's important to have anti-virus software at the Exchange level and at the Outlook level is because not everyone uses Outlook. Imagine that a user needs to check their E-mail from home one night. Chances are that you probably haven't driven to the user's house and set up Outlook on their home computer. They are probably going to use OWA to check their E-mail. If the user happens to open an infected message through OWA, then there is no Outlook integrated anti-virus software protecting them. The user is probably going to unleash the virus unless you have taken steps at the server level to neutralize it.

Physical security

I don't want to spend a lot of time on this one, because it isn't directly related to Exchange, but good physical security is imperative. Anyone with physical access to your servers can hack them in a matter of minutes. The person needs absolutely no hacking experience, because there are so many system recovery utilities available that can double as hacker tools. The bottom line is that you must be able to control physical access to your Exchange Server.

Administrative groups

Another thing that you need to take into account while planning a secure Exchange deployment is administrative control. You need to take into consideration who will need administrative control over the Exchange organization, and whether they will need to control the entire Exchange organization, or just part of it.

If you work for a large company, then chances are that no one administrator has full control over everything. If this is the case, then you will need to split the Exchange organization into multiple administrative groups. You can then place individual servers into specific administrative groups. You may then delegate control over each administrative group to control who is an Exchange Administrator over the servers in each group.

As you delegate control over administrative groups, you should be aware that there are three different levels of control that you can grant. There is an Exchange View Only Administrator. This is basically a training mode in which the administrator is free to explore the administrative group, but not to make changes. There are also Exchange Administrator and Exchange Full Administrator roles. Both of these roles can fully manage the administrative group. The difference is that the Exchange Full Administrator role has the rights to delegate administrative control to others, while the Exchange Administrator role does not.

Server level security

Another thing that you should do when planning a secure Exchange deployment is to plan on hardening individual Exchange Servers. This means doing things like making sure that none of the Exchange Servers are functioning as a domain controller. You should also make a list of all of the services that are running on each server and decide whether or not those services are really necessary. The more services you can disable, the more secure the server becomes.

After the Exchange Servers are up and running, one of the first things that you should plan on doing is running the Microsoft Exchange Server Best Practices Analyzer tool (BPA). The BPA is a utility that is designed to verify that your Exchange Servers are optimally configured for both performance and security. You can download the BPA from Microsoft. I recommend running BPA about once a month.

Loss-of-service threats

I have always believed that security isn't just about keeping the bad guys out, but rather is about protecting your organization against anything that could prevent the system from functioning the way that it is supposed to. After all, a massive server crash with no backup could be even more damaging to the organization than a large scale attack by a hacker.

That being the case, I recommend focusing some of your planning effort on backup and recovery options. Once you decide how you are going to back up your Exchange organization, you should decide how you are going to test your backups on occasion. I have seen several organizations that did not know that their backups were faulty until the time came to restore them.

If protecting against down time is your goal, you might consider clustering your Exchange Servers. If clustering is beyond your budget, then you might consider using servers that have some redundant parts as a way of reducing the chances that a hardware failure will bring the server down. While you are planning the hardware requirements for your Exchange organization, don't forget battery backups for your servers and for the switches that they are connected to.

Trust MOM

One last thing that I recommend doing is to implement Microsoft Operations Manager. Microsoft Operations Manager (MOM) is designed to watch over your servers and take proactive action if it detects that a problem is about to happen. For example, if MOM senses that a server is low on disk space, it may be able to delete some temp files to free up more space. Often times, MOM can prevent a problem from ever occurring. If MOM foresees a problem that it isn't going to be able to prevent, it can be configured to alert you so that you can take action.