Chapter 2 - Securing Your Exchange Environment

Article
03/24/2009

This chapter is part of the Security Operations Guide for Exchange 2000 Server.

Many organizations build a number of their critical business processes around the functionality of Microsoft Exchange. It can be very difficult to deal with any period of time without the various services (e-mail, calendaring, contact information, collaborative applications and so on) that Exchange provides.

One area of risk to continued Exchange 2000 operations is malicious attack, either from within your organization or outside. The risk is increased in the case of Exchange because it is so widely accessible. Chances are that almost every person in your organization has access to Exchange, and you may even make it available over the Internet.

In this chapter, we examine many of the steps you can take to minimize the risk of malicious attacks to your Exchange 2000 environment.

Note: As you make changes to your Exchange 2000 environment, it is vital that you thoroughly document each of those changes. For more information on change and configuration management in Exchange, see Microsoft Exchange 2000 Server Operations. For further details, see the "More Information" section at the end of this chapter.

General Exchange Security Considerations

When considering how to increase the security of Exchange, it is important to remember that Exchange is actually a number of processes which communicate with each other on local and remote computers. Specifically, Exchange servers need to communicate with other Exchange servers, domain controllers and a number of different clients. IIS is integral to the functionality of Exchange and Exchange servers can even be accessed through the file system. This series of complicated relationships means that when attempting to lock down Exchange servers you should consider many different components. These include:

Service security
File security
IIS security
Registry entries
Underlying Windows 2000 security
Domain controller/global catalog security
Active Directory security
Exchange database security
Exchange transport mechanisms

Exchange Service Dependencies

The aim of this guide is to help you secure your Exchange 2000 environment as much as possible without affecting the core functionality of Exchange. One key area to look at is Exchange services. Exchange runs on Windows 2000, and requires some Windows 2000 services to be running either to install the product or for it to continue to function properly. Some Exchange services are also dependent on other Exchange services.

The diagram shows the services that run on an Exchange server by default and the dependencies they have on each other.

Figure 2.1: Exchange server services dependencies

In this guide we recommend settings for many of these services, which are normally configured to start automatically by default. You will be able to disable some of the services, but this will result in some lack of functionality at the server. You will need to decide whether this loss of functionality is appropriate for your environment.

Installing Exchange

Exchange 2000 is a schema modifying application. This means that when setup /forestprep is run, the schema container is modified. Subsequently, when each Exchange 2000 server is installed, the configuration container is modified to include the appropriate Exchange 2000 objects. In practice this means that the account running setup /forestprep needs schema admin permissions, while any account used to install Exchange requires Exchange Full Administrator permissions.

Note: For more information on Exchange 2000 permissions, see Microsoft Exchange 2000 Internals: Permissions Guide. For further details, see the "More Information" section at the end of this chapter.

As with all aspects of permissions management, you should ensure that administrators only have the rights necessary to do their job. High level permissions should be particularly closely guarded. You should consider keeping the Schema Admins group empty by default and explicitly add a user to the group in order to run setup /forestprep. Keeping the Schema Admins group empty is a good general practice as it ensures that you are always alerted before any application would modify the schema.

As part of setup /forestprep, the schema administrator has an opportunity to specify an Exchange 2000 administrator account. This account is granted Exchange Full Administrator rights over the Exchange organization and can therefore perform subsequent Exchange installations. One way of minimizing your security risks during installations is to create a specific universal security group that will have the right to install Exchange. You can then define the group as an Exchange Full Administrator. This will allow you to tightly control who can install Exchange by controlling the membership of the group.

Exchange 2000 Patch Management

To keep Exchange as secure as possible over time, you will need to make sure you remain current on the latest patches. There are two elements to this making sure the operating system is up to date and making sure that Exchange is up to date. If the operating system is vulnerable then Exchange 2000 is also vulnerable, so you should treat the security of the operating system very seriously on Exchange servers.

There are a number of utilities available that will keep you current on Windows 2000 service packs, hotfixes and patches. Microsoft supplies two utilities to help you with this Hfnetchk and The Microsoft Baseline Security Analyzer.

There are a number of security updates that have emerged since Windows 2000 Service Pack 2. Fortunately, many of these are grouped together as the Security Rollup Package for Windows 2000 see the "More Information" section at the end of this chapter for details. You will also need to ensure that you are fully up to date on IIS vulnerabilities and Internet Explorer vulnerabilities.

Exchange 2000 vulnerabilities are significantly rarer than Windows 2000 vulnerabilities and are not currently reported by the tools mentioned in this section. You should ensure that you are notified of any new patches to your environment by Microsoft. If you subscribe to Microsoft Security Bulletins, you will receive these notifications automatically.

Note: For further details on receiving Microsoft Security Bulletins, see the "More Information" section at the end of this chapter.

Note: For more information on patch management in a Windows 2000 environment, see Security Operations Guide for Microsoft Windows 2000 Server.

Note: For further details on the recommended configuration and updates for Exchange 2000, see the "More Information" section at the end of this chapter.

Securing the Client Environment

Exchange 2000 is a client server application. It is therefore very important when considering the overall security of your Exchange environment that you also examine the clients that will be used.

Exchange supports a large number of different clients. As part of your risk management strategy you should examine which are strictly required and limit yourself to those clients. Make sure that you use current and patched versions of the client software, regularly checking for client security updates as these can be just as important as the server.

An important weapon in keeping the client secure is the user. If you educate the user on how to use the client in a responsible manner, it will reduce the risks you face from attack. For example, users should be educated about e-mail viruses, virus hoaxes, chain letters and unsolicited mail.

Note: For information on securing communications between the client and the server, see Chapter 4 Securing Exchange Communications.

Protecting Against Address Spoofing

One of the most common ways of attacking an e-mail system is by manipulating the From: field in an e-mail message. Simple Mail Transfer Protocol (SMTP) does not check to verify a user's identity, but you can perform some actions in Exchange to try and minimize message spoofing.

One of the most insidious problems with address spoofing is external attackers using the e-mail address of an internal user. This can be used in a number of ways, often as a form of social engineering, to persuade another user to give up confidential information, which in turn leads to further attack.

By default, Exchange 2000 will resolve an e-mail address in its address book to the name used in the Global Address List. This can make it very difficult to tell if a message has actually originated outside the organization. You can change the default behavior, so that mail from outside the organization always remains unresolved. If you then educate the users to look for unresolved e-mail addresses, it will help you guard against this form of address spoofing.

Note: For more details on ensuring that mail from outside the Exchange organization remains unresolved, see the Knowledge Base Article 288635, "XIMS: ResolveP2 Functionality in Exchange 2000 Server."

If you are receiving messages directly from other domains on the Internet, you can configure your SMTP virtual server to perform a reverse Domain Name System (DNS) lookup on incoming e-mail messages. This verifies that the senders mail server Internet Protocol (IP) address (and fully qualified domain name) of the sender corresponds to the domain name listed in the message.

Reverse lookup does place an additional load on the Exchange server. It also requires that the Exchange server is able to contact the reverse lookup zones for the sending domain.

Note: For more information on using reverse DNS lookup, see Knowledge Base Article 319356, "HOW TO: Prevent Unsolicited Commercial E-Mail in Exchange 2000 Server."

Anti-Virus Measures

One of the more significant threats to your environment is viruses transmitted through e-mail. E-mail viruses may attack the computer systems themselves or they may attack the e-mail environment, by flooding the system with messages to the point of overload. You need to ensure that you have adequate protection against viruses in your environment.

You should consider protecting against viruses at the firewall, at or outside the SMTP gateway, at each Exchange server and on every client.

Note: For more information on anti-virus software on Exchange servers, see Knowledge Base Article 245822, "XGEN: Recommendations for Troubleshooting an Exchange Computer with Antivirus Software Installed."

At the client level, Outlook 2002 blocks many attachments, preventing them from being viewed and therefore potentially causing damage to your environment. However, you should bear in mind that if you also allow the use of Outlook Web Access (OWA), that the OWA client will not block these attachments.

Note: For more information on protecting against virus attack and what to do in the event of an incident, see Microsoft Exchange 2000 Server Operations.

Protecting Against Unsolicited Mail (Spam)

Unsolicited mail can be a major problem for many organizations. It is costly in a number of ways, from lost user time dealing with mail, to wasted bandwidth and storage space in carrying and storing unnecessary mail.

Unsolicited mail can be very difficult attack to guard against. However, there are a number of measures you can take which will reduce the amount of unsolicited mail you receive.

Educating Users

The users on your network form a key defense against unsolicited mail. This type of mail is often a result of social engineering on your network, and it is important to educate your users on how to avoid it. For example, your users may receive unsolicited mail which includes a disclaimer, stating that if you wish to be removed from the mailing list you should respond to the mail, with the word REMOVE in the subject line. More often than not this is just a means of verifying that an e-mail address is valid so that the address can then be used again. Users should be educated not to respond to unsolicited e-mail under any circumstances. They should also be educated not to forward on unsolicited mail to co-workers.

Unsolicited Mail Features in Outlook 2002

Outlook 2002 has some built-in features that will help protect your users against unsolicited mail. Outlook can search for certain phrases in e-mail messages and automatically move messages containing these phrases from your Inbox to any folder you specify, including a junk e-mail folder created by Outlook or your Deleted Items folder.

Outlook stores the list of terms it uses to filter for unsolicited e-mail in a folder called filters.txt. This file contains a list of senders of unsolicited mail. It also contains phrases which, if they appear in the mail, will result in them being treated as unsolicited mail. Filters.txt can be modified either directly, or through the Outlook 2002 interface.

When you first begin using these features or if you modify them at any time, you should make sure that your users check for messages that have been removed from the inbox, to ensure that valid messages have not been removed accidentally.

Note: For more details on preventing unsolicited mail in Outlook 2002, see the article "Manage Junk and Adult Content Mail in Outlook 2002" in the Microsoft Office Assistance Center. See the "More Information" section for further details.

Unsolicited Mail Features of Exchange 2000

Features built into Exchange 2000 can help you prevent unsolicited mail. In particular, you can prevent mail from being delivered if there is no sender specified, or if the mail is from a particular domain or domains. You can perform filtering across all Exchange servers, or you can determine specific SMTP virtual servers which will perform filtering.

Note: For more details on filtering unsolicited mail using Exchange 2000 Server, see the Knowledge Base article 276321, "XADM, How to Filter Junk Mail in Exchange 2000."

Note: You can guard further against unsolicited e-mail using the message screener. This is covered in Chapter 4, "Securing Exchange Communications".

Protecting Against Denialof-Service Attack

Denial-of-service attacks are generally very difficult to guard against. However, there are a number of settings in Exchange that will help you to do so. The message limits parameters configured on the SMTP virtual server, allow you to specify a maximum number of recipients per message, a maximum message size, a maximum number of messages per connection and so on. These limits will help to ensure that a denial-of-service attack using mail transport is very difficult.

Note: For more information on setting message limits, see Knowledge Base article 319356, "HOW TO: Prevent Unsolicited Commercial E-Mail in Exchange 2000 Server."

Another form of denial-of-service attack could come from sending a large number of mails to a particular server until it runs out of disk space. You can minimize the chance of this happening by setting storage limits on mailboxes and public folders.

Note: For more information on setting storage limits, see Knowledge Base article 319583, "HOW TO: Configure Storage Limits on Mailboxes in Exchange 2000."

Using Permissions and Administrative Groups to Control Access to Exchange 2000

As with any application in your environment, when you define the permissions for Exchange, you should look at the roles your Exchange administrators will have in the environment and give them only the necessary permissions. To simplify the process, Exchange 2000 uses administrative groups. An administrative group is a collection of Exchange 2000 objects that are collected together for the purpose of managing and delegating permissions. An administrative group may contain policies, routing groups, public folder hierarchies, servers, conferencing objects, and chat networks. For example, if your organization has two sets of administrators that manage two sets of servers running Exchange 2000, you can create two administrative groups that contain those two sets of servers. Based on the administrative model that your organization uses, you can develop an administrative plan that fits your needs.

The easiest way to assign permissions to administrative groups (and to the Exchange organization) is using the Exchange Administration Delegation Wizard. You will need to be logged on as a user with Full Control over the Exchange organization to use the wizard. To start the Exchange Administration Delegation Wizard, you should right-click the organization or administrative group in Exchange System Manager, then click Delegate Control.

Three administrative roles are provided:

Table 2.1 Administrative Roles in Exchange 2000

Role	Description
Exchange View Only	Grants permissions to list and read the properties of all objects below that container. Unless the administrator will need to modify object properties, always assign this role.
Exchange Administrator	Grants all permissions except for ability to take ownership, change permissions, or open user mailboxes. If the administrator will need to add objects or modify object properties, but will not be required to delegate permissions on the objects, assign this role.
Exchange Full Administrator	Grants all permissions to all objects below that container except for the ability to open user mailboxes or impersonate a user's mailbox, including the ability to change permissions. Assign this role only to administrators who are required to delegate permissions to objects, or to those administrators who will need to add new servers to the administrative group.

In some cases you will find that using the Exchange Administration Delegation Wizard does not provide enough granularity in assigning security. You can modify the security tab on the individual objects within Exchange. However, by default, the security tab is only displayed on the following objects:

Address Lists
Global Address Lists
Databases (Mailbox stores and Public Folder stores)
Top Level Public Folder Hierarchy

Normally, you will not need to modify the security options on other Exchange objects, however, it is possible to display the security tab on all Exchange objects.

Note: Be careful when changing permissions on Exchange objects. Incorrectly assigning deny permissions can lead to an inability to see Exchange objects in Exchange System Manager.

To display the Security tab on all Exchange objects

Start Regedt32.exe.
Locate the following key in the registry:

HKEY_CURRENT_USER \Software \Microsoft \Exchange \ExAdmin
On the Edit menu, click Add Value , and then add the following registry value:

Value Name : ShowSecurityPage

Data Type : REG_DWORD
Value : 1
Close Registry Editor.

This change takes effect immediately; you do not need to restart Exchange System Manager.

Note: As you are modifying a key within HKEY_CURRENT_USER, the change will only affects the logged on user at the computer you are working on.

Centralized and Distributed Administration

Generally, with respect to administration, there are two core models: centralized and distributed. The type of model you use depends upon the specific needs of your organization.

Centralized Administrative Model

The simplest model is a centralized model. Companies using this model delegate authority for managing their Exchange servers to one person, department or group. To implement this model, create a single administrative group containing all Exchange 2000 objects and assign permissions on the Exchange 2000 organization object.

Distributed Administrative Model

In the distributed model, more than one administrative group is created to represent logical groupings of the organization. These groupings may be geographical, political, or any other logical division of the organization. For example, within the same location, an organization may have three largely autonomous business units. Each business unit has its own IT department and is responsible for maintaining their own IT staff, budget, and responsibilities. Using the distributed administrative model, they can manage their own Exchange administrative tasks.

Mixed Administrative Model

In reality, it's likely that most implementations will neither be purely centralized or distributed, but rather will gravitate towards one model or the other. One useful model is to allow certain configuration choices to be made at the administrative group level, with the more significant ones being made centrally. For example, you may wish to allow administrators of each administrative group to be able to determine time periods for maintenance, but want to ensure that message tracking and mailbox storage limits are enforced throughout the organization.

Creating an Environment to Support a Mixed Administrative Model

There are a number of steps you will need to perform in order to support a mixed administrative model. These include:

Creating one or more management administrative groups for the items under centralized control.
Creating Exchange System Policies to centrally control individual settings.
Assigning the appropriate security to ensure that certain settings cannot be altered by local administrators.

Creating Management Administrative Groups to Centralize Control

Typically, administrative groups are used to manage servers. However, as already mentioned, administrative groups are just a collection of objects that you are placing together for administrative purposes. This can help you to maintain tight administrative control over your Exchange organization. For example, you may determine that you want routine configuration of Exchange servers to be under the control of regional administrators. However, you wish routing decisions and the public folder hierarchy to be under centralized control. To achieve this, you would create a management administrative group and move the routing groups and public folders to that administrative group. If you then control the permissions on the management administrative group appropriately, you can prevent local administrators from changing those elements of Exchange.

Using Exchange System Policies to Enable a Mixed Administrative Model

You can use Exchange 2000 to create policies to control mailbox stores, public folder stores and servers. Policies can be applied to any or all of the corresponding objects in Exchange. If applied with the appropriate security settings, you can use polices to centrally control certain aspects of configuration, while altering other properties locally. Settings which may be configured in this way include message tracking and mailbox limits.

You should consider using system policies in conjunction with a management administrative group. If you place the policies in this group, local administrators will not be able to change the policy settings if they do not have the rights over the management administrative group.

The table shows settings in a simple environment, with two administrative groups for server control. In this example, administrators of each of the London and New York administrative groups have limited control over their servers and are able to make day to day routine changes. However, the servers have policies applied which they cannot alter, nor do they have any control over the management of the public folder hierarchy or routing between servers.

Table 2.2 Example of Mixed Administrative Model for Exchange 2000

Name	Contains	Policies Applied	Permissions
Management	Public Folders Container Routing Groups Container System Policies Container	None	Exchange Management Allow Full Control Group A Admin Deny Full Control Group B Admin Deny Full Control
London	Servers	Server Policy Mailbox Store Policy Public Folder Store Policy	Exchange Management Allow Full Control Group A Admin Allow Full Control
New York	Servers	Server Policy Mailbox Store Policy Public Folder Store Policy	Exchange Management Allow Full Control Group B Admin Allow Full Control

Controlling User Administration

Under Exchange 2000, mailbox-enabled users, mail-enabled users and mail-enabled contacts are all controlled from Active Directory directory services Users and Computers settings. This allows you to delegate administrative authority over users at the organization unit level, separate from the rest of Exchange and give you great granularity of control.

Note: To modify Exchange settings for a user, the administrator must also have at least Exchange View Only Administrator Settings on the Exchange organization.

Summary

There are many elements to increasing the security of an Exchange 2000 environment. First, you need to ensure that the underlying Windows environment is as secure as possible (see Security Operations Guide for Microsoft Windows 2000 Server for more details.) Then you will need to take measures to increase the security of Exchange 2000. This chapter and the following chapters will help you with those measures.