Securing Exchange Communications

Article
03/24/2009

Updated : February 6, 2004

In This Module

This module describes how to make the communication between Microsoft Exchange servers and clients more secure. It shows how to enable encrypted remote procedure call (RPC) traffic between the Microsoft Outlook messaging and collaboration client and server. Detailed instructions are provided about the use of a Microsoft Internet Security and Acceleration (ISA) Server to secure traffic from a Web client to the Exchange server. Exchange front-end/back-end topology is explained and how you can use it to further secure your client/server traffic. Finally, ways of securing Simple Mail Transfer Protocol (SMTP) traffic are described.

Objectives

Use this module to:

Encrypt RPC communication between Outlook 2002 and Exchange.
Digitally sign and encrypt messages using Outlook 2002.
Secure Web browser communication with an Exchange server using an ISA server with and without secure sockets layer (SSL.)
Encrypt communication between an ISA server and Outlook Web Access (OWA) front-end servers using SSL.
Encrypt communication between OWA front-end server and back-end Exchange servers by using Internet Protocol Security (IPSec.)
Secure SMTP traffic by using an ISA server with the Message Screener or by using a separate SMTP Gateway.
Prevent unwanted SMTP relaying.

Applies to

This module applies to the following products and technologies:

Microsoft Exchange Server 2000
Microsoft Outlook 2002
Microsoft Windows 2000 operating system Active Directory directory service
Microsoft Internet Security and Acceleration (ISA) Server

How to Use This Module

This module is designed to act as a supplement to Security Operations for Microsoft Windows 2000 Server (Microsoft Press, ISBN: 0-7356-1823-2). You are strongly advised to read that guide in full before going on to read this module. Sections of this module will depend directly on information in Security Operations for Microsoft Windows 2000, and this will be indicated in the text where appropriate. You are also advised to read Microsoft Exchange 2000 Server Operations (Microsoft Press, ISBN: 0-7356-1831-3), which will provide you with more information about general Exchange 2000 operations.

The aim of this module is to help you secure your Exchange 2000 environment as much as possible without affecting the core functionality of Exchange. This module focuses explicitly on the operations required to create and maintain a secure environment on servers running Exchange 2000. You should use this guidance as part of your overall security strategy for Exchange, not as a complete reference to cover all aspects of creating and maintaining a secure environment.

This module should be used in conjunction with the module, "Securing Your Exchange Environment" and the module, "Securing Exchange 2000 Servers Based on Role."

This module provides detailed methodology to secure Exchange front-end and back-end servers using encrypted RPC, ISA servers, SSL and IPSec and also how to secure SMTP transport. The steps are modular and give clear instructions on how to configure the servers with the settings. You can apply them to a new or existing Exchange environment.

Introduction

When you increase the security of any network, you should not only examine the security of the computers themselves, but also the data that travels between them. As with any system, the best approach is to look at the functionality that is available, and examine what you require, considering the risk posed by each piece of functionality.

In this guidance we are assuming that you require the ability to send and receive e-mail over the Internet and access Exchange over the Internet using Outlook Web Access. If you do not require that functionality, you will be able to lock down your systems more completely. On the other hand, if you require POP3 and IMAP4 functionality, you will need to open up the environment to accommodate them.

The front-end/back-end environment suggested in this guidance will allow you to send mail to and from the Internet, and to offer Exchange access over the Internet. This module looks at how to secure that communication, and also examines securing communication at the client.

Note: It is possible to access Outlook over the Internet by using an Exchange remote procedure call (RPC) application filter provided with ISA Server. This method of accessing Exchange is not covered in this guidance. See the "Configuring and Securing Microsoft Exchange 2000 Server and Clients" white paper and the Microsoft Exchange 2000 Server Hosting Series (Microsoft Press, ISBN: 0-7356-1829-1 and 0-7356-1830-5) listed in the "More Information" section.

Securing Communications in Outlook 2002

There are a number of measures you can take in Outlook 2002 to increase the security of your communications. These include:

Encrypting the MAPI connection from Outlook 2002 to the Exchange server
Signing and encrypting messages using S/MIME certificates

Encrypting the MAPI Connection from Outlook 2002 to Exchange Server

Windows 2000 has a built-in security feature allowing for 128-bit encryption of RPC communication. MAPI connections take place over RPC and so you can take advantage of this feature to increase the security of your connection from the Outlook 2002 client to the Exchange server.

To enable RPC encryption of the of the MAPI connection from Outlook 2002 to Exchange server

In Outlook 2002, click Tools, and then E-mail accounts.
Click Next.
Ensure the Exchange server is selected, and click Change.
Click More Settings.
Click the Advanced tab.
Check When using the Network.
Click OK.
Click Next.
Click Finish.

Note: You can also specify this setting when setting up User profiles in Outlook 2002.

RPC encryption only encrypts the data from the MAPI client to the Exchange server. It does not encrypt the messages themselves.

Signing and Encrypting Messages

Outlook 2002 has the ability to sign and encrypt messages for delivery to internal or external recipients. For this encryption you will need a certificate. If you want to deliver signed and/or encrypted e-mail to Internet recipients, you will need to use a recognized certificate (known as a Digital ID) from a third-party vendor.

Once you have a certificate installed on the client, you can begin to send signed and encrypted messages using S/MIME. You can only send encrypted mail to other users if you have access to their public key. This is achieved by having the other user send you a signed message and then adding that user to your contacts. You will now have their public key available.

Note: For more information on signing and encrypting messages see Knowledge Base article Q286159, "Encryption and Message Security Overview."

Key Management Service

If you wish to routinely send signed and encrypted messages between users inside your Exchange organization, you should consider using the Key Management service provided with Exchange 2000. This service uses Windows 2000 Certificate Services and provides access to public keys with secure, centralized access to private keys. This gives clients seamless access to signed and encrypted messages, allowing them to send these messages to any other security-enabled recipient in the global address list (GAL).

Note: If you use Key Management Server with a certificate authority (CA) that is subordinate to a third-party CA, you can integrate your Key Management service with others on the Internet.

Securing OWA Communications

Upon initial review, communications with OWA are very simple. Web browsers communicate with OWA servers for e-mail. This occurs over port 80, or port 443 if the communication is secure. However, while clients do connect to front-end servers over port 80 or port 443, those front-end servers then need to communicate with domain controllers in their domain to authenticate the users. They also need to communicate with Exchange back-end servers to actually access information from the appropriate mailbox or public folder.

OWA front-end servers can be secured by placing them inside a perimeter network (also known as the demilitarized zone, or DMZ), with the back-end server inside the inner firewall. However, in order for this to work, a large number of ports have to be opened on the inner firewall.

Using ISA Server to Secure OWA

To minimize the ports you need to open on the inner firewall, you can use an application layer firewall, such as Microsoft Internet Security and Acceleration (ISA) Server. ISA Server allows you to position both your SMTP server and your OWA front-end server behind the firewall. Using Server Publishing and Web Publishing rules, ISA Server will impersonate internal servers to the outside world without placing those servers in the DMZ.

Note: For a list of the ports used for communication between front-end and other servers, see the "Exchange 2000 Front-end and Back-end Topology" white paper listed in the "More Information" section at the end of the module.

Figure 1 shows an ISA Server publishing an OWA Server to OWA clients on the Internet:

Figure 1 Secure Firewall Structure

Figure 1 Secure Firewall Structure

Note: In this configuration, external DNS entries for the front-end OWA server will need to refer to the IP address published on the ISA Server, not the address of the OWA front-end server.

Note: If you are not able to change your existing two firewall infrastructure to accommodate ISA Server, you can place ISA Server inside your current inner firewall and pass TCP port 443 through to the ISA server.

Firewalls will help protect your servers from being attacked. However, you also need to protect the data that is traveling to and from your servers. When Web browser clients on the Internet access Exchange via OWA using HTTP, the following occurs:

An HTTP request is sent to the ISA Server from the Web browser. If permitted by the ISA publishing rules, the requests are passed to the OWA front-end servers.
ISA Server establishes a new HTTP connection to the front-end server with its own IP address as the source IP address.
The HTTP requests are processed on the OWA front-end server. As part of the processing, the OWA front-end server:
- Authenticates the user and contacts against the global catalog server to determine the location of the user mailbox.
- Resolves the IP address of the user mailbox server.
The OWA front-end server establishes a new HTTP session to the back-end Exchange server.

As part of the configuration of Microsoft Internet Information Services (IIS) to support OWA you need to enable basic authentication. Integrated Windows authentication will not work as the only protocol being used for communication is either HTTP or HTTPS, and you must not use anonymous access as this will open up your e-mail environment to anyone on the Internet.

Basic authentication means that over an HTTP connection, passwords and e-mail will pass over the Internet in an unencrypted form. If no additional encryption methods are used, these packets continue to travel unencrypted between the ISA Server and the OWA front-end server in clear text. After OWA performs authentication, the same unencrypted information, including passwords, will be sent over HTTP between OWA front-end server and back-end server. To prevent this from happening, it is vital to encrypt the user credentials along the entire path between the Web browser and the back-end Exchange server. This can be accomplished by:

Securing communication between Web browsers and ISA Server using SSL encryption.
Securing communication between ISA Server and OWA front-end servers using SSL.
Securing communication between OWA front-end servers and back-end Exchange servers using IPSec encryption.

We will examine each of these in turn.

Securing Communication Between Web Browsers and ISA Servers

To encrypt the data between Web browsers and an ISA Server using SSL, you need to install an SSL certificate on the ISA Server and the appropriate SSL listener. Your certificate should be issued by a globally trusted CA because it will be used by external Web clients that may not be part of your organization's infrastructure.

Configuring ISA Server to Support SSL Communications

ISA Server can be configured in a number of ways to accept SSL requests from Web browsers. It can:

Receive SSL communications and pass them on to servers inside the firewall.
Decrypt SSL communications and pass them on unencrypted to the back-end.
Decrypt SSL communications and re-encrypt them before passing them on to the back-end.

Note: Decrypting and re-encrypting SSL communication requires ISA Server SP1 or later. The below procedures will not work correctly unless ISA Server SP1 or later is installed.

Of these three methods, the most secure is to decrypt the packets and re-encrypt them again, because this allows the ISA Server to inspect the data for vulnerabilities. It also protects the data from attack inside the ISA Server.

Note: The laws of certain countries may prevent you from decrypting data and inspecting it at an intermediary point in your network. You should check the legal implications of this solution before adopting it.

Note: To improve the performance and reduce the overhead of SSL, you should consider using SSL accelerator network adapters.

To successfully encrypt the data, you should ensure the following:

The ISA Server certificate for OWA needs to have the common name, also known as friendly name, that matches the Fully Qualified Domain Name (FQDN) used by the Web browsers to reference OWA resources. For example, if the OWA URL used by the client is https://mail.nwtraders.com/exchange the certificate common name should be mail.nwtraders.com.
The certificate must be imported into the Personal computer store of the ISA Server or servers publishing the OWA resources. When importing the certificate into your ISA Server, make sure that Mark the private key as exportable is enabled.
To avoid accidental transmission of clear text passwords, ISA Server should allow only secure channel and reject clear text HTTP connections for the published OWA site.

ISA Server uses a Web Publishing Rule to make the OWA server available to Internet clients. However, before creating the Web Publishing Rule, Web Publishing itself must be prepared on the ISA Server. This is done by configuring Incoming Web Requests and Outgoing Web Requests.

Note: Before completing the following procedure, you need to import your external certificate.

To configure Incoming Web Requests

Start ISA Managment.
Right-click your ISA Server and select Properties.
Click the Incoming Web Requests tab.
Select Configure listeners individually per IP Address, and then click Add.
Select your ISA Server and select the external IP address of your ISA Server.
Select Use a server certificate to authenticate web clients.
Click Select and select the certificate for the FQDN clients will be using to access the SSL site.
Click OK.
Select Enable SSL Listeners.
Click OK.
Click OK.
Click Save the changes and restart the service(s), and then Click OK.

To configure Outgoing Web Requests

Note: Performing the following procedure will prevent users on the internal network from using the ISA Server as a proxy server to access web sites on the Internet. This procedure is not needed to make OWA available through ISA but is included for additional security.

Start ISA Managment.
Right-click your ISA Server and select Properties.
Click the Outgoing Web Requests tab.
Select Configure listeners individually per IP Address, ensure no IP addresses are listed, and then click OK.
Click Save the changes and restart the service(s), and then Click OK.

You are now in a position to configure Web Publishing to support OWA.

To configure Web Publishing for OWA

In ISA Management, expand your ISA Server, and then expand Publishing.
Right-click Web Publishing Rules, select New, and then select Rule.
Provide a name, such as OWA - <FQDN of OWA Front-end Server> and then click Next.
Verify All destinations, and then click Next.
Verify Any request is selected, and then click Next.
Select Redirect the request to this internal Web server (name or IP Address), click Browse and select your OWA front-end server.
Select Send the original host header to the publishing server instead of the actual one (specified above), and then click Next.
Click Finish.
In the folder pane click Web Publishing Rules, then double-click the new rule.
Click the Bridging tab.
Select Require secure channel (SSL) for published site, select Require 128-bit encryption, and then click OK.

Note: You will also need to configure appropriate rules for port 80 and port 443 on the appropriate routers and firewalls in your environment.

Note: For more information on publishing SMTP and OWA using ISA Server, see Knowledge Base articles Q290113, "How to Publish Outlook Web Access Behind ISA Server" and Q308599, "How to Configure ISA Server to Publish Exchange for OWA."

Encryption between ISA Servers and OWA Front-End Servers

To encrypt HTTP traffic between ISA Server and an OWA front-end server, you need to install an SSL certificate on the OWA front-end servers. ISA Servers and OWA front-end servers are part of your organization's infrastructure, so the OWA front-end certificate can be issued by your organization's internal root CA or any of its trusted subordinate certificate authorities.

To request a certificate for your OWA front-end server

Note: The following steps assume you have a CA installed in your environment.

Start Internet Services Manager on your OWA front-end server.
Right-click Default Web Site, and then click Properties.
Click the Directory Security tab, and then click Server Certificate.
Click Next, click Create a new certificate, and then click Next.
Click Send the request immediately to an online certificate authority option button, and then click Next.
In the Name field, type a name, and then click Next.
In the Organization field, type your organization name.
In the Organizational unit field, type your organization unit name, and then click Next.
In the Common name field, type the FQDN of your OWA front-end server, and then click Next.
Type the state and city information, and then click Next.
In the Certification authorities drop-down list box, verify that your certificate authority is selected, and then click Next.
Click Next to submit the request, and then click Finish to complete the wizard.
On the Directory Security tab, in the Secure communications group box, click Edit.
Select Require secure channel (SSL), select Require 128-bit encryption, and then click OK.
On the Directory Security tab, in the Anonymous access and authorization control group box, click Edit.
Select Basic authentication (password is sent in clear text), and then click Yes to acknowledge the warning.
Clear all other options, and then click OK.
Click OK.
Click OK to close the Inheritance Overrides dialog box, and then close Internet Services Manager.

Note: The common name is the FQDN of the OWA server because this matches the OWA Publishing Rule Property on the ISA Server. ISA Server checks the validity of the OWA Web certificate, along with the certificate trust chain verification and certificate expiration date, during the publishing process.

Encryption between OWA Front-End Servers and Back-End Exchange Servers

You cannot encrypt data between OWA front-end servers and back-end servers using SSL. However, as both front-end and back-end servers are running Windows 2000, you can use IPSec for this encryption. IPSec has the benefit of being significantly faster than SSL.

Note: To improve performance and reduce the overhead of IPSec, you should consider using specialized network adapters which offload IPSec processing to the adapter.

IPSec allows you to control which protocols are accepted by the network adapter, blocking or allowing certain ports, and encrypting others. In the case of front-end/back-end server communication, you need to ensure that port 80 is encrypted.

IPSec is controlled through IPSec policies which are defined within Windows 2000 Group Policy.

Table 1. IPSec Policy Settings

Policy	Settings
OWA front-end	Port 80 Outbound - Encrypt Port 80 Inbound - Block
Back-end	Port 80 Inbound - Encrypt

OWA front-end

Port 80 Outbound - Encrypt

Port 80 Inbound - Block

Back-end

Port 80 Inbound - Encrypt

It is possible to block inbound requests from the front-end server, because the front-end server initiates all communications with the back-end server. Blocking these requests will avoid accidental transmission of user credentials in clear text and minimize the risk of buffer overflow attacks on the front-end server.

Creating the OWA Front-End Server IPSec Policy

The first policy to create and configure is for the OWA front-end server.

To create the outbound TCP 80 filter

Start Active Directory Users and Computers.
Expand Member Servers, expand Application Servers, and then expand Exchange 2000.
Right-click the OWA Front-end Servers OU, and then click Properties.
Click the Group Policy tab.
Select the OWA Front End Incremental GPO.
Click Edit.
Expand Windows Settings, Security Settings, and then right-click IP Security Policies on Active Directory.
Click Manage IP filter lists and filter actions.
Click Add.
In the Name box, type Outbound TCP 80 - OWA FE.
In the Description box, type This filter matches outbound TCP 80 traffic on the OWA front-end server.
Click Add, and then click Next.
In the Source Address drop-down list box, verify My IP Address is displayed, and click Next.
In the Destination Address drop-down list box, verify Any IP Address is displayed, and click Next.
In the Select a protocol type drop-down list box, select TCP, and click Next.
In the Set the IP protocol port, verify From any port is selected, select To this port and type 80.
Click Next, and then click Finish.
Click Close to close the IP Filter List window.

To create the inbound TCP 80 filter

Click Add.
In the Name box, type Inbound TCP 80 - OWA FE.
In the Description box, type This filter matches inbound TCP 80 traffic on the OWA front-end server.
Click Add, and then click Next.
In the Source address drop-down list box, select Any IP Address, and then click Next.
In the Destination address drop-down list box, select My IP Address, and the click Next.
In the Select a protocol type drop-down list box, select TCP, and click Next.
In the Set the IP protocolport, verify From any port is selected, select To this port, and then type 80.
Click Next, and then click Finish.
Click Close.
Click Close.

To create the block action to be used with the inbound TCP port 80 filter

From the Group Policy window, right-click IP Security Policies on Active Directory, and then select Manage IP filter lists and filter actions.
Click the Manage Filter Actions tab.
Click Add, and then click Next.
In the Name box, type Block, and then click Next.
Select Block, and then click Next.
Click Finish.

To create the encrypt action to be used with the outbound TCP port 80 filter

Click the Manage Filter Actions tab.
Click Add, and then click Next.
In the Name box, type Encrypt, and then click Next.
Select Negotiate security, and click Next.
Select Do not communicate with computers that do not support IPSec, and then click Next.
Verify High (Encapsulated Secure Payload) is selected**,** and then click Next.
Click Edit Properties, and then click Finish.
Click Add.
Select Custom (for expert users), and then click Settings.
Verify only Data integrity and encryption (ESP) is selected.
In the Encryption algorithm, select 3DES.
Click OK.
Click OK.
Select Custom, and then click Move up.
Click OK.
Click Close.

To create the IP Security policy, apply the filters and specify the actions

Right-click IP Security Policies on Active Directory, select Create IP Security Policy, and then click Next.
In the Name box, type Block-Encrypt TCP 80 traffic - OWA FE, and click Next.
Verify Activate the default response rule is selected, and click Next.
Verify Windows 2000 default (Kerberos V5 protocol) is selected, and click Next.
Verify Edit properties is selected, and click Finish.
On the Rules tab, click Add, and then click Next.
Verify This rule does not specify a tunnel is selected, and click Next.
Verify All network connections is selected, and click Next.
Verify Windows 2000 default (Kerberos V5 protocol) is selected, and click Next.
In the IP filter lists select Inbound TCP 80 - OWA FE, and then click Next.
In the Filter Actions box, click Block, and then click Next.
Verify Edit properties is cleared, and click Finish.
On the Rules tab, click Add, and then click Next.
Verify This rule does not specify a tunnel is selected, and click Next.
Verify All network connections is selected, and click Next.
Verify Windows 2000 default (Kerberos V5 protocol) is selected, and click Next.
In the IP filter lists select Outbound TCP 80 - OWA FE, and then click Next.
In the Filter Actions box, click Encrypt, and then click Next.
Verify Edit properties is cleared, and then click Finish.
Click Close.

To apply the outbound filter to Group Policy

In the Group Policy contents pane, right-click Block-Encrypt TCP 80 traffic - OWA FE, and then click Assign.
Close Group Policy, and then click OK.

To apply , Group Policy to the OWA front-end server

On the OWA front-end server start a Command Prompt.
Type secedit /refreshpolicy machine_policy /enforce, and press ENTER.
Restart the server.

Creating the Back-End Server IPSec Policy

The policy on the back-end server encrypts inbound port 80 traffic.

To create the Inbound TCP 80 filter

Start Active Directory Users and Computers.
Expand Member Servers, expand Application Servers, and then expand Exchange 2000.
Right-click the Back-end Servers OU, and then click Properties.
Click the Group Policy tab.
Select the Back End Incremental GPO.
Click Edit.
Expand Windows Settings, Security Settings, and then right-click IP Security Policies on Active Directory.
Click Manage IP filter lists and filter actions.
Click Add.
In the Name box, type Inbound TCP 80 - BE.
In the Description box, type This filter matches inbound TCP 80 traffic on the Back-end Server.
Click Add, and then click Next.
In the Source Address drop-down list box, verify My IP Address is displayed and click Next.
In the Destination Address drop-down list box, verify Any IP Address is displayed, and click Next.
In the Select a protocol type drop-down list box, select TCP, and click Next.
In the Set the IP protocol port, verify From any port is selected, select To this port, and type 80.
Click Next, and then click Finish.
Click Close to close the IP Filter List window.

To create the IP Security policy, apply the filters and specify the actions

Right-click IP Security Policies on Active Directory, select Create IP Security Policy, and then click Next.
In the Name box, type Encrypt TCP 80 traffic - BE, and click Next.
Verify Activate the default response rule is selected, and click Next.
Verify Windows 2000 default (Kerberos V5 protocol) is selected, and click Next.
Verify Edit properties is selected, and click Finish.
On the Rules tab, click Add, and then click Next.
Verify This rule does not specify a tunnel is selected, and click Next.
Verify All network connections is selected, and click Next.
Verify Windows 2000 default (Kerberos V5 protocol) is selected, and click Next.
In the IP filter lists, select Inbound TCP 80 - BE, and then click Next.
In the Filter Actions box, click Encrypt, and then click Next.
Verify Edit properties is cleared, and click Finish.
Click Close.

To apply the inbound filter to Group Policy

In the Group Policy contents pane, right-click Encrypt TCP 80 traffic - BE, and then click Assign.
Close Group Policy, and then click OK.

To apply , Group Policy to the back-end server

On the OWA front-end server start a Command Prompt.
Type secedit /refreshpolicy machine_policy /enforce, and press ENTER.
Restart the server.

Note: You may wish to also apply IPSec settings at each local computer. This ensures that IPSec will still be used, even in the event of a problem accessing Group Policy from the domain controller.

Monitoring IP Security connections

After you have configured IPSec, it is a good idea to verify its functionality by auditing IPSec-related events and by using the IP Security Monitor tool.

To start and configure the IP Security Monitor

On either the OWA front-end or the back-end server, to start the IP Security Monitor tool, click Start, click Run, and in the Open box, type ipsecmon.
Click Options and change the defaultRefresh Seconds value from 15 to 1.
Click OK.

To verify successful configuration of IPSec

Generate traffic between the OWA front-end and back-end servers by having a user send e-mail using OWA.
Switch to IP Security Monitor, which should show the traffic between your OWA front-end server and the back-end server is encrypted.

Note: For more information on IPSec, see the "Step-by-Step Guide to Internet Protocol Security (IPSec)", see the "More information" section for details.

Securing SMTP Communications

Every Exchange back-end server will run SMTP, as it is responsible for mail transport between Exchange servers and across the Internet. In this section we will look at how to provide SMTP communications to your network while minimizing the risk of attack to your organization.

Using ISA Server to Secure SMTP

As with your OWA front-end server, it is possible to minimize the number of ports open on your inner firewall by using the capabilities of ISA Server. In this case you can use the ISA Server Publishing feature to publish your SMTP server, positioning the Exchange server itself behind the firewall. ISA Server will impersonate the internal SMTP server without you having to place Exchange inside the perimeter network.

Note: In this configuration, external DNS entries for SMTP will need to refer to the IP address published on the ISA Server, not the address of the SMTP server.

Note: If you are going to implement any form of authentication over port 25, you should enable SSL authentication for SMTP.

Note: You cannot publish outgoing SMTP on an ISA Server if the server is an active member of an ISA array.

Using Content Filtering with the Message Screener

Content filtering enables the SMTP filter, which accepts incoming traffic on port 25, inspects it, and passes it on only if the rules allow it. The filter can accept or reject messages based on the username or domain name of the sender, attachments or keywords and even provide some protection against buffer overflow attacks. However, for the SMTP filter to have full functionality, you should also install the Message Screener.

Message Screener is a separate utility supplied with ISA Server. It can be installed in a number of different configurations; however the most secure implementation of the message screener is to place it on a server running IIS with an SMTP virtual server. This virtual server would then communicate with Exchange in order to send and receive e-mail. This has the advantage of further isolating your Exchange server from the edge of the internal network.

Note: For information on deploying Message Screener, see the Knowledge Base article Q315132, "HOW TO: Configure SMTP Message Screener in ISA Server 2000." For more details, see the "More Information" section at the end of this module.

Additional Measures to Secure SMTP

Publishing SMTP through ISA Server and using the SMTP filter with Message Screener will help you protect your Exchange SMTP servers. However, there are some other actions you should consider.

Using a Separate SMTP Gateway

As part of your defense-in-depth strategy, you may wish to protect your Exchange back-end servers from SMTP attack by using a separate SMTP gateway inside your network. All incoming mail from the Internet would encounter this server before any of the Exchange servers. This server would not be part of any Windows 2000 domain and would therefore not be running Exchange. The advantage of this is that an external attacker trying to use SMTP to attack Exchange servers would encounter the separate SMTP server first. Taking down the SMTP server may shut down your ability to send e-mail over the Internet, but you will still be able to send internal e-mail. You could also run anti-virus software on this server.

Note: For more information on setting up and configuring an SMTP virtual server see Knowledge Base article Q308161, "HOW TO: Set Up and Configure an SMTP Virtual Server in Windows 2000."

Preventing Mail Relay

Mail relaying is the process of using an interim server to accept and then resend mail to recipients on another server. It can be used for legitimate means. For example, roaming users may wish to connect to your SMTP server in order to send mail when they are outside your network.

If you choose to allow limited relaying from outside your network, you should be very sure to regulate what is done, and ensure authentication from those users who need to take advantage of it (authentication is enabled by default). If you open up SMTP relaying too widely, you will soon find very large amounts of mail passing through your SMTP server, which will affect the performance of your environment and add to the amount of unsolicited mail on the Internet. You may also find that you become listed on spam block-lists which may prevent your legitimate mail getting to its destination.

Even authorized mail relaying can cause problems for your mail server. Attackers use the fact that your mail server accepts authenticated requests to attempt a dictionary attack against the server.

A good approach to protecting your server is to disable relaying as much as possible. External users do not need to connect directly to your SMTP server in order to send mail, as they can use OWA.

To protect your Exchange Servers against mail relay, you consider the following measures on your internal SMTP virtual servers:

Allowing only anonymous connection to your SMTP Servers.
Preventing computers which successfully authenticate from relaying.
Allowing only SMTP connections from specific IP addresses.

You will need to open up this configuration a little on SMTP Servers at the gateway. The exact settings will depend on your message flow and the configuration of your ISP's mail server. However, the best way to increase your security is to lock down your systems completely to prevent relaying and then finding the minimum settings required to allow e-mail to flow successfully.

Note: SMTP for authenticated computers is required if you are going to support IMAP and POP3. If you choose to enable these protocols, you should consider creating a separate virtual server for this traffic and using SSL to protect the virtual server.

Note: For more information on preventing unwanted SMTP relaying in Exchange, see the TechNet article, "Controlling SMTP Relaying in Microsoft Exchange" and Knowledge Base article Q319356, "HOW TO: Prevent Unsolicited Commercial E-Mail in Exchange 2000 Server."

Summary

You cannot consider Exchange to be as secure as possible unless you take measures to secure its data flow. If you are allowing OWA over the Internet, this is particularly important, as without security in place, passwords are passed as clear text over the Internet and inside your internal network. Use the guidelines in this module to increase the security of your Exchange communications.