If you would like to read the other parts in this article series please go to:
- Hardening an Exchange Server 2003 Environment (Part 2)
- Hardening an Exchange Server 2003 Environment (Part 3)
- Hardening an Exchange Server 2003 Environment (Part 4)
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: