Exchange Server 2003 is only as secure as Windows Server 2003. Therefore, it is imperative to secure Windows Server 2003 to ensure it conforms to the security standards for the organization.
Security works best when it is applied in layers. It is much more difficult to rob a house, for example, if a thief not only has to break through the front door, but also has to fend off an attack dog and disable a home security system. The same concept applies to server security: multiple layers of security should be applied so that the difficulty in hacking into a system becomes that much greater.
Windows Server 2003 seamlessly handles many of the security layers that are required, using Kerberos authentication, NTFS file security, and built-in security tools to provide for a great deal of security out of the box. Once Windows Server 2003 is secured according to the organization's requirements, Exchange Server 2003 security can be integrated to conform to the security requirements of the organization.
An Exchange Server 2003 server can be very restrictive in what resources are accessible but if the server is not physically secured, an unauthorized user or hacker can more easily gain unauthorized access. For example, simply unplugging the server can have serious repercussions even if the unauthorized user was not able to access messaging data.
Physical security should be a requirement for any organization because it is the most common cause of security breaches. Despite this fact, many organizations have loose levels, or no levels, of physical security for their mission-critical servers.
Servers should be physically secured behind locked doors, preferably in an environmentally controlled room. Other methods of physically securing servers includes hardware locking devices, video surveillance, and more.
All servers should be configured to allow only administrators to physically log in to the console. By default, Exchange Server 2003 does not allow any members of the domain users group local logon privileges. This prevents non-administrators from logging on to the server even if they can gain physical access to the server.
Auditing is a way to gather and keep track of activity on the network, devices, and entire systems. By default, Windows Server 2003 enables some auditing, whereas many other auditing functions must be manually turned on. This allows for easy customization of the features the system should have monitored.
Auditing is typically used for identifying security breaches or suspicious activity. However, auditing is also important to gain insight into how the servers are accessed. Windows Server 2003's auditing policies must first be enabled before activity can be monitored.
Audit policies are the basis for auditing events on a Windows Server 2003 system. Depending on the policies set, auditing may require a substantial amount of server resources in addition to those resources supporting the server's functionality. Otherwise, it could potentially slow server performance. Also, collecting lots of information is only as good as the evaluation of the audit logs. In other words, if a lot of information is captured and a significant amount of effort is required to evaluate those audit logs, the whole purpose of auditing is not as effective. As a result, it's important to take the time to properly plan how the system will be audited. This enables the administrator to determine what needs to be audited and why without creating an abundance of overhead.
Audit policies can track successful or unsuccessful event activity in a Windows Server 2003 environment. These policies can audit the success and failure of events. The types of events that can be monitored include:
Account Logon Events Each time a user attempts to log on, the successful or unsuccessful event can be recorded. Failed logon attempts can include logon failures for unknown user accounts, time restriction violations, expired user accounts, insufficient rights for the user to log on locally, expired account passwords, and locked-out accounts.
Account Management When an account is changed, an event can be logged and later examined. Although this pertains more to Windows Server 2003 than Exchange Server 2003, it is still very relevant because the Exchange directory is stored in Active Directory.
Directory Service Access Any time a user attempts to access an Active Directory object that has its own System Access Control List (SACL), the event is logged.
Logon Events Logons over the network or by services are logged.
Object Access The object access policy logs an event when a user attempts to access a resource (for example, a printer or shared folder).
Policy Change Each time an attempt to change a policy (user rights, account audit policies, trust policies) is made, the event is recorded.
Privilege Use Privileged use is a security setting and can include a user employing a user right, changing the system time, and more. Successful or unsuccessful attempts can be logged.
Process Tracking An event can be logged for each program or process that a user launches while accessing a system. This information can be very detailed and take a significant amount of resources.
System Events The system events policy logs specific system events, such as a computer restart or shutdown.
The audit policies can be enabled or disabled through either the local system policy or Group Policy objects. Audit policies are located within the Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy folder, as shown in Figure 12.2.
An important way to secure your messaging environment is by securing distribution and mail-enabled security groups. For instance, CompanyABC is a medium-sized company with 1,000 users. To facilitate company-wide notifications, the HR Department created a distribution group called “All Employees”. All employees are members of the “All Employees” group. By default there are no message restrictions for new groups, meaning that anyone can send to this list. If CompanyABC has an Internet Mail SMTP Connector, this group will also have an SMTP address.
Consider what would happen if a new user sent an email to “All Employees” advertising a car for sale. Now imagine that the user sent it with a read receipt and delivery notification requested. This can have disastrous results if the server is unable to process this many requests at once.
In a similar scenario, intentions are not as innocent as the new user trying to sell a car. In fact, it can be an attempted denial of service (DOS) attack. An attacker sends an SMTP message to the “All Employees” group with a delivery notification receipt requested and spoofs the Return to address field as the same SMTP address as the distribution group. The effect is (1 + 1000 + 1000 * 1000) = 1,001,001 messages! Since a delivery notification receipt was requested, this single email results in over 1 million messages processed by the system.
Exchange Server 2003 now offers an easy solution for this problem by configuring message restrictions for the distribution group. To secure distribution groups so that only authenticated users can use it, do the following:
1. | Open Active Directory Users and Computers from the Start, All Programs, Microsoft Exchange menu. |
2. | Right-click the distribution group and select Properties. |
3. | Select the Exchange General tab and under the Message restrictions section, check the check box to Accept messages: From authenticated users only. |
4. | Click OK when done. |
An administrator could further restrict the usage of this group by allowing only a specific security group to use it. To restrict access to the distribution group to a specific user or group, do the following:
1. | In the Active Directory Users and Computers snap-in, right-click the distribution group and select Properties. |
2. | Select the Exchange General tab and under the Message restrictions section, select the Only from radio button. |
3. | |
4. | Click OK when finished. |
Depending on the role that an Exchange Server 2003 server will fulfill, not all services that are installed by default are necessary for the server to function. It is considered good practice to limit the number of entry points (services) into a server. Any services that are not required for the system to function should be disabled. Note that this can be performed using a customized security template.
Files secured on Windows Server 2003 are only as secure as the permissions that are set on them. Subsequently, it is good to know that Windows Server 2003, for the first time in a Microsoft operating system, does not grant the Everyone group full control over share-level and NTFS-level permissions. In addition, critical operating system files and directories are secured, to disallow their unauthorized use.
Despite the overall improvements made, a complete understanding of file-level security is recommended to ensure that the file-level security of a server is not neglected.
NOTE
The Exchange Server 2003 installation process requires that partitions on the server are formatted as NTFS.
The Microsoft Baseline Security Analyzer (MBSA) is a tool that identifies common security misconfigurations and missing hotfixes via local or remote scans of Windows systems. MBSA provides users with the ability to scan a single Windows system and obtain a security assessment as well as a list of recommended corrective actions. Furthermore, administrators may use the MBSA tool to scan multiple functional roles of a Windows-based server on the network for vulnerabilities to help ensure systems are up-to-date with the latest security-related patches.
To run MBSA, do the following:
1. | Download the latest security XML file to use with MBSA. (This is downloaded automatically if the server is connected to the Internet.) This file contains a list of current service packs and hotfixes that should be applied to a system. |
2. | Keep the default settings and scan the server(s). |
As mentioned in Chapter 11, “Client-Level Security,” Microsoft has gone to great lengths to provide secure and reliable products. Moreover, it has worked closely with companies, government agencies, security consultants, and others to address security issues in the computer industry.
In addition to Microsoft security standards and guidelines, it is advisable that organizations use recommended best practices compiled by the National Institute of Standards and Technologies (NIST) and the National Security Agency (NSA). Both NIST and NSA provide security lockdown configuration standards and guidelines that can be downloaded from their Web site (http://www.nist.gov and http://www.nsa.gov respectively).
Security templates are a practical and effective means to apply security policies and configurations to Exchange Server 2003 servers. Although security templates are provided with Windows Server 2003, it is recommended to customize them prior to applying them using the Security Configuration and Analysis Microsoft Management Console (MMC) snap-in.
This not only ensures that computers are identically configured with the same security configurations but it also is an easy way to configure appropriate security measures for those computers that are not managed using GPOs.
NOTE
For more information on customizing and using security templates, refer to Chapter 11.
Service packs (SPs) and hotfixes for both the operating system and applications, such as Exchange Server 2003, are vital parts to maintaining availability, reliability, performance, and security. There are several ways an administrator can update a system with the latest SP: CD-ROM, manually entered commands, Systems Management Server (SMS) Windows Update, or Microsoft Software Update Server (SUS).
NOTE
Thoroughly test and evaluate SPs and hotfixes in a lab environment before installing them on production servers. Also, install the appropriate SPs and hotfixes on each production server to keep all systems consistent.
Windows Update is a Web site that scans a local system and determines whether there are updates to apply to that system. Windows Update is a great way to update individual systems, but this method is sufficient for only a small number of systems. If administrators choose this method to update an entire organization, there would be an unnecessary amount of administration.
Software Update Services (SUS) minimizes administration, management, and maintenance of mid- to large-sized organizations communicating directly and securely with Microsoft to gather the latest security updates and SPs (for Windows XP SP1 and Windows 2000 SP4 or higher).
The security updates downloaded onto SUS can then be distributed to either a lab server for testing (recommended) or to a production server for distribution. After these updates are tested, SUS can automatically update systems inside the network.
NOTE
You can find more information on SUS and download the product from
IIS is an integral part of Windows Server 2003 and it has come a long way from its predecessors especially in terms of security. Several key enhancements such as a reduced attack surface and enhanced application isolation deliver a robust and secure Web platform.
IIS installs only the features needed to fill its defined role or function. It works by turning off unnecessary features, much like the IISLockdown utility performed, thus reducing the attack surface available to attackers. For previous versions of Windows, the IISLockdown tool was available as a separate download. It is now, however, built into IIS. IIS maintains a UrlScan.ini file with a specific section for DenyUrlSequences and can limit the length of specific fields and requests. This functionality replaces some of the features of URLScan, a complementary component of using IISLockdown.
Although IIS does a good job at installing and enabling only what is needed, it is important to review IIS security configurations on the organization's Exchange Server 2003 servers. Table 12.1 summarizes key hardening aspects of IIS as well as presents other key recommendations for securing the Web components on the messaging server.
Although not all inclusive, Table 12.2 provides a quick checklist of recommended security precautions to take on an Exchange Server 2003 server.