Hardening an Exchange Server 2003 Environment (Part 1)

If you would like to read the other parts in this article series please go to:

The next version of Exchange Server will introduce many new long awaited security features. While we wait for Exchange 2007 to go RTM, in this series of 4 articles I’ll explain what can be done to make an Exchange Server 2003 environment more secure.

Introduction

This article is not just about hardening Exchange servers, but also about many other security aspects that can make the whole messaging infrastructure more secure. Namely, I’ll focus on these areas:

  • People
  • Servers
  • Clients
  • Messages

Some of my clients simply refuse to install any Microsoft product on their perimeter networks. A few of them even have this written in their security policy. It is my belief and conviction that the alleged lack of security of Microsoft software is just one of those popular myths. I could mention a couple of studies, but these can sometimes be contradictory. So I ask you to believe in my work experience, that a well configured and well managed (and these two conditions are extremely important!) Microsoft server is as secure as some UNIX flavor or a proprietary OS.

The security recommendations I’ll write about are targeted for Exchange Server 2003 systems, although some of the more generic ones could be applied in different versions. In fact they are generic best practices and can (and should) be used on every IT infrastructure.

A final word before starting the recommendations: when tweaking security settings there’s always the risk of service breakdown. So be sure to always test the changes in a controlled environment and ensure you have all the means to rollback to the previous state.

Basic Security Best Practices

Although there are a wide variety of complex and sophisticated measures that you can take to increase the security of your Exchange Server organization, you should not overlook the following basic precautions.

Item

Action

Network Security

– Secure Active Directory

– Require strong passwords

– Follow the principles of least privilege

– Implement an anti-virus solution

Server Security

– Physically protect your servers

– Remove all unnecessary services

– Apply the latest service pack and all subsequent hotfixes

Messaging Security

– Create lists of approved IP addresses and domain names

– Enable logging and monitor your servers

– Prevent SMTP relay

Data Security

– Implement a disaster recovery plan to recover compromised or lost data

Table 1

Know your infrastructure

Do you really know your infrastructure? Do you know where the critical assets of your messaging systems are located? Do you know the risks you incur and how to mitigate them?

Security has a lot to do with knowledge. The first step you must take before defining your security strategy is to update yourself about the network topology, server configuration, systems configuration, user behavior and any other relevant aspect of your Organization.

An effective security strategy also identifies the ports that are associated with each service that your Exchange Server organization uses. In order to reduce the attack surface, you should shut down access to ports that you are not using. The following table lists the Exchange Server ports and their associated services:

Port

Service

25

SMTP

80

HTTP (Hypertext Transfer Protocol)

88

Kerberos authentication protocol

102

MTA (message transfer agent)—X.400 connector over TCP/IP (Transmission Control Protocol/Internet Protocol)

110

POP3

119

NNTP

135

Client/server communication RPC (remote procedure call) Exchange administration

143

IMAP

389

LDAP (Lightweight Directory Access Protocol)

443

HTTP (Secure Sockets Layer (SSL))

465

SMTP (SSL)

563

NNTP (SSL)

636

LDAP (SSL)

993

IMAP4 (SSL)

995

POP3 (SSL)

3268, 3269

Global catalog lookups

Table 2: Exchange Server ports

No single security precaution will ensure the security of your Exchange Server 2003 organization. You need to understand the security risks to which most companies are vulnerable. By identifying security risks and implementing technologies and methods to reduce those risks, you will reduce your exposure to security attacks.

The following table identifies the most common types of security attacks.

Type of Security

Risk Characteristics

Data theft or tampering

Copying, changing, or listening to data that is transmitted over a network or from a disk.

Forgery

Passing data as a third party.

Denial of service

Preventing connections to a server or network by flooding that server or network with incorrect and incomplete data. This causes the receiving server to fill its buffers or queues until it can time out all of the erroneous packets.

Trojan horse

A malicious, security-breaking program that is disguised as something benign, such as a game or a joke.

Virus

A program that searches out other programs and infects them by embedding copies of itself in them so that they become Trojan horses. When the corrupted programs are run, the embedded virus also runs. This is how the virus propagates itself. Viruses are typically invisible to the user.

Spoofing

Impersonating another person by configuring that person’s e-mail address in the perpetrator’s own e-mail client.

Mail-relaying

Relaying mail through your company’s servers with the intent of disguising the actual origin of the mail.

Table 3: Types of security attacks

Administrative Roles

There’s a known security practice which is the principle of least privilege. This principle states that a user or in this case, an administrator, must be able to manage only information and resources that are immediately necessary. The idea is to enhance protection of data and functionality from faults and malicious behavior.

In our case, in an Exchange environment where you have multiple groups of administrators, you may encounter a situation in which some administrators will make configuration changes to objects that they should not modify. To prevent such situations from happening, there are some things that can be done:

  • Configure additional Administrative Groups – Administrative groups provide a way to group objects together (such as servers, policies, routing groups, and public folder hierarchies) and define the scope of permissions for the group.
  • Use Exchange Administration Delegation Wizard – use this Wizard to grant administrative permissions to a user or a group.
  • Assign Administrative Roles – An administrative role is a collection of Exchange 2003 objects for the purpose of managing and delegating permissions.

The following table lists the administrative roles in Exchange 2003:

Role

Organization rights

Administrative Group rights

Exchange Full Administrator

• Full Control permissions on the MsExchConfiguration container (this object and its subcontainers). 

• Deny Receive-As permissions and Send-As permissions on the Organization container (this object and its subcontainers).

• Read permissions and Change permissions on the Deleted Objects container in the Configuration naming context (Config NC) (this object and its subcontainers). 

• Read, List object, and List contents permissions on the MsExchConfiguration container (this object only). 

• Read, List object, and List contents permissions on the Organization container (this object and its subcontainers). 

• Full Control, Deny Send-As, and Deny Receive-As permissions on the Administrator Groups container (this object and its subcontainers). 

• Full Control permissions (except for Change) on the Connections container (this object and its sub-containers). 

• Read, List object, List contents, and Write properties permissions on the Offline Address Lists container (this object and its subcontainers).

Exchange Administrator

• All permissions (except for Change permissions) on the MsExchConfiguration container (this object and its subcontainers). 

• Deny Receive-As permissions and Send-As permissions on the Organization container (this object and its subcontainers). 

• Read, List object, and List contents permissions on the MsExchConfiguration container (this object only). 

• Read, List object, and List contents permissions on the Organization container (this object and its subcontainers). 

• All permissions (except for Change, Deny Send-As, and Deny Receive-As permissions) on the Administrator Group container (this object and its sub-containers). 

• All permissions (except for Change permissions) on the Connections container (this object and its subcontainers). 

• Read, List object, List contents, and Write properties permissions on the Offline Address Lists container (this object and its subcontainers). 

Exchange View Only Administrator

• Read, List object, and List contents permissions on the MsExchConfiguration container (this object and its sub-containers).

• View Information Store Status permissions on the Organization container (this object and its sub-containers). 

• Read, List object, and List contents permissions on the MsExchConfiguration container (this object only). 

• Read, List object, and List contents permissions on the Organization container (this object only).

• Read, List object, and List contents permissions on the Administrator Groups container (this object only). 

• Read, List object, List contents, and View Information Store Status permissions on the Administrator Groups container (this object and its sub-containers). 

• Read, List object, and List contents permissions on the MsExchRecipientsPolicy container, the Address Lists container, Addressing, Global Settings, System Policies (this object and its sub-containers). 

Table 4: Administrative Roles in Exchange Server 2003

In some cases, the Exchange Administration Delegation Wizard does not provide enough granularity for assigning security permissions. Therefore, for individual objects within Exchange, you can modify the settings on the Security tab.

Logging Capabilities

OK, we’re not going to talk about Exchange transaction logs, those critical components of the Exchange database architecture. The logs I’m interested in have to do with extra and useful information that record some actions that occur in your environment. From the security perspective it’s not only important that you have those logs, but also that you monitor them regularly, not only after something bad happens.

There are a number of logging capabilities in Exchange 2003, such as diagnostic logging, message tracking, activity logging, and audit logging. The volume of data these logs can generate in a day can be enormous, so in case you run out of disk space, Exchange will dismount its stores.

As a best practice you should create an audit plan before implementing audit policy:

  • Consider the resources that you have available for collecting and reviewing an audit log.
  • Decide what type of information you want to gain by collecting audit events.
  • Collect and archive security logs across your organization.

If you follow these guidelines, in case an intrusion or a security breach occurs, you have all the means to conduct a proper investigation.

Although there’s a large variety of logging capabilities in Exchange, here’s the list of the most significant logs for an Exchange environment:

  • Event Viewer system security log
  • SMTP Virtual Server logs
  • HTTP logs
  • Message tracking logs

Summary

This ends part 1 of this article. In part 2 I’ll cover the infrastructure part of an Exchange environment, how to harden your servers and what measures can be taken to further protect you against security risks.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top