Hardening Front-End Servers

 

Hardening your Exchange front-end servers is similar to hardening the back-end server, with the optional (but recommended) step of configuring and running URLScan on your HTTP front-end servers.

There are six general configuration areas for hardening font-end servers:

  • Hardening services

    Many services are not used, but are enabled by default and should be disabled if the corresponding functionality is not required.

  • Hardening file access control lists (ACLs)

    The file ACL configuration for the front-end servers is identical to that of the back-end servers.

  • Enabling additional services (optional)

    Enable any additional front-end services that are required for your organization

  • Running URLScan (optional, but recommended)

    Although running URLScan is not required for the services to run, it is highly recommended as a mechanism for further hardening your front-end HTTP servers.

  • Dismounting the mailbox store and deleting the public folder store (optional, but recommended)

    For front-end servers that are not SMTP front-end servers, you can dismount and delete these stores.

    Note

    If you plan to delete the public folder store, you should delete it before applying the Exchange security policies so the changes can replicate to the other Exchange servers.

Applying the Exchange_2003-Frontend_V1_1.inf security template (available from the Microsoft Download Center) to your front-end servers is the most efficient mechanism for performing the hardening configurations that are described in this section. Furthermore, after you apply the Exchange_2003-Frontend_V1_1.inftemplate, you can use the protocol-specific security templates to enable the appropriate services.

For information about how to deploy the Exchange Group Policy Security Templates, see "Deploying the Exchange Group Policy Security Templates."

Before You Get Started

Before you begin hardening the front-end servers in your organization, consider the following:

  • Exchange 2003 includes the following applications:

    • Outlook Web Access

    • Outlook Mobile Access

    • Exchange Server ActiveSync®

    These applications allow your users to access Exchange information from their personal computers or mobile devices. These applications all use a combination of Hypertext Transfer Protocol (HTTP) and WebDAV. By default, Outlook Web Access and Exchange Server ActiveSync are enabled. Outlook Mobile Access is also installed by default, but the service is disabled on new installations of Exchange 2003.

  • POP3 and IMAP4 clients may also use front-end servers to access mailboxes. In these cases, they also use a front-end server as an SMTP gateway.

  • Using a firewall server such as Internet Security and Acceleration (ISA) Server 2004 to regulate access for HTTP, RPC over HTTP, POP3, and IMAP4 protocol traffic is an essential building block for a more secure messaging system. For information about how to deploy ISA 2000 with Exchange 2003, see Using ISA Server 2000 with Exchange Server 2003. For information about how to deploy ISA 2004 with Exchange 2003, see Using ISA Server 2004 with Exchange Server 2003.

  • It is recommended that you isolate your ISA server in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet), allowing only the essential ports into your organization. The Exchange front-end server can then communicate freely with all Windows and Exchange services over IPSec. For a list of ports that Exchange 2003 may use, see "Ports Used in Exchange Server 2003."

  • The IIS Lockdown (IISlockd.exe) tool is needed only for Windows 2000 Server. In Windows Server 2003, IIS Lockdown is a core part of Internet Information Services (IIS). If you are running Exchange 2003 on a server running Windows 2000, see the Microsoft Knowledge Base article, "XADM: Known Issues and Fine Tuning When You Use the IIS Lockdown Wizard in an Exchange 2000 Environment."

  • It is recommended that you use Secure Sockets Layer (SSL) and cookie authentication for Outlook Web Access. SSL helps maintain confidentially by encrypting message traffic between the client and Exchange 2003. Cookie authentication improves security by timing out inactive, non-domain connections and forcing the user to re-authenticate after a period of inactivity. For more information about cookie authentication, see the Exchange Server 2003 Administration Guide.