10. Exchange Security

Introduction

Email has become critically important to many businesses, and the security landscape surrounding Exchange has come to reflect that importance. When Exchange 5.5 first shipped, spam was not a problem, most organizations had no need for antivirus software, and many took a rather casual approach to patch management and network security. Now, though, there are some baseline best practices that are very widely adhered to. Because this is a generalized Exchange cookbook, we can’t go into exhaustive detail for all of them; the recipes in this chapter focus on the most important things that you should do to secure your Exchange servers.

Messaging security generally breaks down into three areas: confidentiality (keeping private material private), integrity (ensuring that message data isn’t tampered with or accidentally damaged), and availability (ensuring that data is available when users need it). Most security solutions focus on providing confidentiality and integrity, and so will the recipes in this chapter.

Where to Learn More

To a greater extent than the other chapters in this book, this chapter assumes that you will do some outside reading—a lot of it, in fact. That’s because the semantics and implementation requirements for messaging security are fairly strict, and there’s a ton of background material that you need to be familiar with to completely secure your Exchange environment against the particular threat model that your organization faces.

The first resource we recommend is the only book we know of written specifically on messaging security, Secure Messaging with Microsoft Exchange Server 2003 (Microsoft Press). The book was written by Paul Robichaux, one of the authors of the book you are now reading, and it deals with every aspect of Exchange security, including threat assessment, patch management, communications and message confidentiality, and providing secure mobile, remote, and wireless access to your Exchange servers. Sample chapters and other related materials are available at http://www.e2ksecurity.com.

Next is the Exchange TechCenter page that Microsoft maintains for Exchange security and protection:

http://www.microsoft.com/technet/prodtechnol/exchange/2003/security.mspx

This page contains links to the wealth of security documentation that Microsoft has produced for Exchange, including:

The Message Security Guide for Exchange Server 2003 (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/exmessec.mspx) describes how to set up and use S/MIME protection for Outlook clients talking to an Exchange Server 2003 server.
The Security Hardening Guide for Exchange Server 2003 (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/exsecure.mspx) describes the process of hardening Exchange Server 2003 servers against attack by applying a set of pre-built security templates for domain controllers, member servers, and Exchange servers. This information is based on the guidance in the Windows Server 2003 Security Guide, which you should also plan on reading.
The Exchange Server Intelligent Message Filter Deployment Guide (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/imfdeploy.mspx) tells you how to install, deploy, and monitor the Intelligent Message Filter antispam tool, a free Exchange Server 2003-only download from Microsoft.
The Solution Accelerator for Exchange Consolidation and Migration (http://www.microsoft.com/technet/itsolutions/ucs/ecm/saecm/OverviewGuide_3.mspx) contains discussions and examples of using Exchange Server 2003 with ISA 2004.
The Using ISA Server 2000 with Exchange Server 2003 (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/uisaex03.mspx) describes using ISA Server 2000 to securely publishing Outlook Web Access (OWA), Outlook Mobile Access (OMA), Exchange ActiveSync (EAS), SMTP, and Outlook interfaces to the outside world.
The Working with Active Directory Permissions in Exchange Server 2003 Guide (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3ad.mspx) explains what Active Directory permissions are required to install, use, and maintain Exchange, and how you can (and when you should) change those permissions.
The Working with Store Permissions in Microsoft Exchange 2000 and 2003 Guide (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/storperm.mspx) details how Exchange evaluates and uses permissions on items in mailbox and public folder databases, and how Exchange evaluates Windows user credentials to make access control decisions.

These documents, taken together, provide several hundred pages of extremely detailed information about Exchange security. Unfortunately, if you really want to gain an understanding of how to best secure your Exchange organization, you’ll have to read and absorb these documents, or hire people who have; there aren’t any shortcuts.

10.1. Scanning Exchange Servers for Security Patches

Problem

You want to ensure that your Exchange servers have the most up-to-date set of security patches.

Solution

Download the current version of Microsoft Baseline Security Analyzer (MBSA) tool from http://www.microsoft.com/mbsa. Follow the included instructions to install it on a Windows 2000, Windows XP, or Windows Server 2003 machine that belongs to a domain in the same forest as the servers you want to scan.

Using a graphical user interface

Open MBSA (c:program filesMicrosoft Baseline Security Analyzermbsa.exe).
From the initial MBSA page, choose whether you want to scan a single computer or more than one by clicking the appropriate link:
- If you want to scan a single computer, you can specify it by computer name or IP address.
- If you need to scan multiple computers, you can choose to scan by domain (in which case, MBSA will scan all computers it can see in that domain) or by IP address range.
You can optionally specify a format for the names of the reports produced in either mode; by default, the report name will include the domain name, computer name, and date and time of the scan. To speed up the scans as much as possible, you should uncheck the Check for weak passwords and Check for SQL vulnerabilities boxes (provided, of course, that you’re only scanning your Exchange servers!).
Click Start scan. MBSA will attempt to fetch the latest version of the security updates list from Microsoft’s web site, then it will begin scanning the selected computers.
Wait for the scan to complete; when it does, MBSA will display a detailed report indicating what the scan results look like (we’ll decipher the report format in the Discussion).

Using a command-line interface:

Use the mbsacli.exe tool to scan the computers you’re interested in. With no arguments, mbsacli will scan the local computer. To scan a machine named batman, skipping the SQL and password checks, you’d run the following command:

> mbsacli.exe /c batman /nSQL+Password

The scan will proceed as it does in the GUI version, but the output is different. Instead of a detailed on-screen report, you’ll get a summary that shows which computers and IP addresses were scanned, along with an assessment of each computer’s risk level and the name of the report. The report name is based on the domain and computer name and date/time of the scan (you can override this format with the /o option).

Discussion

We’ve had the ability to check an individual machine for Windows updates since Windows 98 or so, but the built-in Windows Update functionality leaves quite a bit to be desired from an enterprise security standpoint. Instead of allowing individual users, or administrators, to apply ad-hoc patch combinations to individual machines, most companies want a standardized way of determining which patches are necessary, then loading them automatically. MBSA provides the measurement tool; other tools, like the Systems Management Server (SMS), Microsoft Software Update Service (SUS) or its forthcoming successor Windows Update Services (WUS), can be used to get the actual patches on the machine. WUS will actually extend the functionality of Windows Update to include patches for other Windows applications, such as Office and Exchange. There are also a number of third-party patch management applications that offer support for monitoring and managing Exchange servers.

MBSA added support for Exchange in Version 1.2. When you launch MBSA, the first thing it does is attempt to download the current version of the MSSecure.xml file (which is actually available as either raw XML or as a .CAB file). This file enumerates all the available security patches for various versions of Windows and key applications like Exchange. By checking for file versions, modification dates, and the presence of registry keys added when hotfixes are applied, MBSA can usually determine which patches are installed on a given machine. We say “usually” because there have been several well-known cases of patches for which MBSA either falsely reported a fix as being present or baselessly complained that a critical fix was missing. The latest version of MBSA, 1.2.1, has fixed most of these cases, but be forewarned that an MBSA report listing one or more security updates that “could not be confirmed” doesn’t necessarily spell impending doom.

For scanning Exchange servers, you’ll probably want to use the command-line version of MBSA in HFNetChek compatibility mode. This mode makes MBSA work like the HFNetChek tool from which it was partially derived; it’s useful because it allows you to feed it a text file containing a list of NetBIOS computer names or IP address (one per line, with a maximum of 255 lines per file). This makes it easy to script periodic checks of your Exchange servers, using a command line like this:

> mbsacli.exe -hf -fh 
HostsToScan.txt
 
> mbsacli.exe -hf -fip 
IPAddressesToScan.txt

One drawback of HFNetCheck mode is that you can’t use the MBSA-mode options like /n, so you trade off some flexibility in scanning behavior for flexibility in specifying which hosts should actually be scanned. MBSA supports a broad range of command-line options, which are well-described in its documentation.

10.2. Securing SMTP Authentication

Problem

You want to ensure that your Internet-facing Exchange SMTP server is properly secured.

Solution

Using a graphical user interface

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.
Locate the target server, then expand its Protocols container and the SMTP node beneath it.
Right-click the Default SMTP Virtual Server node and select Properties.
Switch to the Access tab and click the Authentication button. The Authentication dialog is shown in Figure 10-1.
Choose the appropriate authentication settings by checking the corresponding boxes. For Internet-facing servers, you must leave anonymous access enabled if you want your server to accept SMTP mail from other servers; you can enable or disable basic and integrated authentication as necessary (see the Discussion section for more on this).
Click OK to accept the authentication settings. They will take effect immediately.

Figure 10-1. The SMTP server authentication dialog

Discussion

Configuring SMTP authentication is a necessary part of securing your Exchange server. SMTP wasn’t originally designed to support authentication, so the IETF has retrofitted authentication via the SMTP AUTH verb as documented in RFC 2554. You can only control authentication at the virtual server level. The Authentication dialog pictured earlier in Figure 10-1 gives you control over which authentication methods a particular virtual server will accept.

The Anonymous access checkbox controls whether your server will accept completely unauthenticated connections. This is the default behavior of most SMTP servers, so for servers that you want to accept mail from the outside world, this checkbox should be set.
The Resolve anonymous email checkbox (enabled only when Anonymous access is marked) controls whether Exchange will attempt to resolve SMTP FROM addresses into names in the GAL. In general, you should leave this turned off. If you enable it, spammers or forgers can inject mail that will appear to have been internally generated. Let’s say we have this option enabled, and a spammer sends mail that claims to be from [email protected] to a user on our server. Our server will resolve that address to the corresponding GAL entry, so the recipient won’t see the bare SMTP address if they’re using OWA or a MAPI client—they’ll see whatever’s defined in the GAL.
The Basic authentication (password is sent in clear text) checkbox enables the use of basic SMTP authentication using the SMTP AUTH verb. When you select this, ESM will warn you that this method doesn’t provide any protection for user credentials as they’re sent over the wire. This is a good warning to heed. If you’re leery of allowing passwords over the wire in the clear, make sure you check the Requires TLS encryption box; this will only allow basic authentication on incoming connections from other servers and clients that support using TLS with SMTP.
If you enable the use of basic authentication with TLS, and you have more than one domain with user accounts, you can specify a default domain in the Default domain field. This is not required, because users can always specify a domain as part of their user name.
The Integrated Windows Authentication checkbox controls whether Exchange will accept Windows authentication methods for logon. These methods may include the use of Kerberos or NTLM credentials; only mail clients and servers that support these methods can use integrated authentication, so for practical purposes, this checkbox might as well be labeled “For Microsoft products only.” (Note that if you enable this setting, clients won’t use it unless you turn on the secure password authentication, or SPA, feature in the client.)
When anonymous access is disabled, the Users button becomes enabled. As its label intimates, you can use this button to allow or deny SMTP privileges to specific users or groups. This is a commonly requested feature for companies that want to further restrict who can send SMTP mail through their servers; by specifying users and groups that should either be denied or granted permissions, you can complement the IP address restrictions described in Recipe 7.21.

In some cases, you might really want to allow only authenticated senders to use your SMTP server. For example, you might set up one virtual server that allows relaying (but only with authentication!) and another that accepts mail from servers on the Internet. In that case, make sure that the Anonymous access checkbox is turned off on the server where you want to require authenticated access.

One area that calls for particular caution is the prevalence of SMTP authentication attacks. These attacks, usually mounted by spammers, are essentially dictionary attacks that attempt to discover user passwords for use with SMTP servers that require authentication. Exchange 2000 and 2003 don’t log failed authentication attempts by default, so you won’t necessarily have an idea that you’re under attack. The logs maintained by the Internet Information Services (IIS) SMTP core don’t record authentication requests, so you can’t watch them for clues either. The only reliable way to monitor attempted attacks using this scheme is to look for packets originated by your Internet-facing mail servers on TCP port 25 with the string “535 5.7.3 Authentication unsuccessful” in them.

There are several protective measures you can take, though:

Ensure that all your user accounts are using strong, complex passwords. This is especially important for the Administrator account, which has a well-known name. (You might consider renaming the Administrator account; this adds a small degree of additional security, although it’s trivial for any legitimate user to discover the correct name from within your network).
Set diagnostic logging on the Connection Manager component (see Recipe 4.7 for directions) of the MSExchangeTransport object to Medium or High. Once you do this, failed connection attempts will result in event ID 1706 and 1707; however, these events don’t indicate the IP address or user name of the failed connection attempt.
Disable authentication on your primary Internet-facing SMTP virtual server. This prevents attackers from mounting dictionary attacks against that server, although it also prevents you from allowing authenticated relay to that server.
If you need authenticated relaying, set up an additional virtual server, preferably using a nonstandard port. Spammers won’t be able to routinely discover this port (unless they do a port scan, which your firewall should prevent) but legitimate users can configure their clients t o use it.

10.3. Enabling IPsec Between Front- and Back-End Servers

Problem

You want to protect traffic between your front- and back-end servers by using IPsec.

Solution

Using a graphical user interface

To create a new IPsec policy for HTTP, POP, and IMAP on the front-end server, do the following:

Log on to the front-end server with an account that has administrative privileges.
Open the Microsoft Management Console (mmc.exe).
From the menu select File→ Add/Remove Snap-In. When the Add Standalone Snap-in dialog box appears, click the Add button.
Select the group policy snap-in from the list (Group Policy Object Editor on Windows 2000, Group Policy on Windows 2003) and click the Add button.
The Select Group Policy Object dialog box appears. Make sure the Group Policy Object field says Local Computer, and click Finish.
Click Close and click OK to return to the management console.
Expand the IPsec policy object, which is located under Local Computer Policy→ Computer Configuration→ Windows Settings→ Security Settings→ IP Security Policies on Local Computer.
Right-click IP Security Policies on Local Computer and select Create IP Security Policy.
When the IP Security Policy wizard appears, click Next.
Give the policy a name (and, optionally, a description) and click Next.
Click Next to keep the default response rule.
In the Default Response Rule Authentication Method dialog box, make sure that Active Directory default (Kerberos V5 protocol) is selected and click Next.
Click Finish; the properties dialog box for the new policy will appear.
Click the Add button and click Next to start the Create IP Security Rule Wizard.
On the Tunnel Endpoint page, make sure This Rule Does Not Specify A Tunnel is selected and click Next.
On the Network Type page, make sure Local Area Network (LAN) is selected and click Next.
In the IP Filter List page, click the Add button. The IP Filter List dialog box will appear.
Give the filter list a name (preferably one that indicates which protocols you’re filtering), add a useful description, then click the Add button.
Click Next to start the IP Filter Wizard.
Give the filter a description (such as “FE-to-BE traffic”) and click Next.
On the IP Traffic Source page, make sure My IP Address is selected in the Source address field, and click Next.
On the IP Traffic Destination page, specify the back-end server by IP address or DNS name, and click Next.
On the IP Protocol Type page, select TCP and click Next.
On the IP Protocol Port page, select the From any port and To this port radio buttons; specify port 80 as the destination port and click Next.
Click Finish.
Repeat steps 14-25 for POP (TCP port 110) and IMAP (TCP port 143) if you’re using them.
Click OK.
In the IP Filter List dialog box, select the filter list you just created and click Next.
Select Require Security and click Next.
In the Authentication Method page, ensure that Active Directory default (Kerberos V5 protocol) is selected and click Next.
Click Finish, click OK, and click OK again.
In the MMC, verify that your new policy appears in the right pane.
Right-click the new policy and use the Assign option to apply it.

To enable the corresponding IPsec policy on the back-end server, do the following:

Log on to the front-end server with an account that has administrative privileges.
Launch the Microsoft Management Console (mmc.exe).
From the menu, select File→ Add/Remove Snap-In. When the Add Standalone Snap-in dialog box appears, click the Add button.
Select Group Policy Editor from the snap-in list and click the Add button.
The Select Group Policy Object dialog box appears. Make sure the Group Policy Object field says Local Computer and click Finish.
Click Close and click OK again.
Expand the IPsec policy object, which will be under Local Computer Policy→ Computer Configuration→ Windows Settings→ Security Settings→ IP Security Policies on Local Computer.
Right-click Client (Respond Only) in the right MMC pane, then select the Assign option.
Verify that the Policy Assigned column for Client (Respond Only) says Yes.
Close the MMC.

Using a command-line interface

To apply IPsec policy to the front-end server, run the following commands:

> netsh ipsec static add policy "FE-to-BE"
> netsh ipsec static add filterlist "FE-to-BE"
> netsh ipsec static add filter filterlist="FE-to-BE" srcaddr=me 
dstaddr=<backEndIP> protocol=TCP 
mirrored=yes srcport=0 dstport=80
> netsh ipsec static add filter filterlist="FE-to-BE" srcaddr=me 
dstaddr=<backEndIP> protocol=TCP 
mirrored=yes srcport=0 dstport=110
> netsh ipsec static add filter filterlist="FE-to-BE" srcaddr=me 
dstaddr=<backEndIP> protocol=TCP 
mirrored=yes srcport=0 dstport=143
> netsh ipsec static add rule name="FE-to-BE" policy="FE-to-BE" 
filterlist="FE-to-BE" conntype="LAN" kerberos=yes filteraction=
"Require Security" activate=yes

Discussion

Deploying IPsec is fairly complex and one recipe can’t really do it justice. The important point for deploying IPsec between front- and back-end Exchange servers is that you must specify which types of traffic you want to protect:

If you just want to protect POP and IMAP credentials, you can protect TCP port 110 (for POP) and TCP port 143 (for IMAP) between the front- and back-end servers. For this to be meaningful, you should also disable unencrypted POP and IMAP access to the front-end; there’s relatively little value in securing the credentials on your network if they’re not secured when passing across the Internet.
If you want to protect message traffic as it travels back and forth, you need to protect TCP port 80 (since the front-end proxies all WebDAV, IMAP, and POP requests to the back-end onto that port), as well as the POP and IMAP ports (which are used to send data back to the clients).
To protect all traffic between the FE and BE, you’ll need to build a much more complex set of filters that include SMTP (TCP 25), DNS (TCP and UDP 53), LDAP (TCP 389 for ordinary LDAP, plus TCP 3268 for LDAP communications with the GC), Kerberos, and RPC traffic.

IPsec policies are stored in a local policy database, so you can apply them to individual machines (as we do in this recipe). The local policy database can be linked to, and automatically refreshed from, a group policy object (GPO), so you can define IPsec policies at the site or domain level, or link them to OUs. This approach is valuable if your Exchange servers are in their own domains or OUs or are using group filtering on Windows 2003 DCs. If not, running scripts like the one shown in the command-line solution (or using the policy import and export features of netsh) is probably the fastest way to get IPsec protection in place on your servers.

10.4. Enabling IPsec on an Exchange Server 2003 Cluster

Problem

You have one or more front-end servers communicating with a clustered back-end server, and you want to protect IMAP, POP, or HTTP traffic passing between them.

Solution

Using a graphical user interface

Open the Registry Editor (regedit.exe).
In the left pane, navigate to:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesPolicyAgentOakley
Click on the Oakley subkey.
In the right pane, right-click the NLBSFlags entry and select Modify.
In the Value data field, type 1 and click OK.
Close the Registry Editor.

Using the command line

On the server where you want to enable IPsec, run the following command:

> reg add HKLMSystemCurrentControlSetServicesPolicyAgentOakley 
/t REG_DWORD /v "NLBSFlags" /d "1" /f

Discussion

You can use IPsec as described in Recipe 10.3 to protect IMAP, POP, and HTTP communications between front- and back-end servers. However, if the back-end server is a cluster, the ordinary setup method doesn’t work well. That’s because the security association (SA) established between the two servers has to be renegotiated when failover occurs. The default interval for SA renegotiation is five minutes, which means that until that interval elapses, the FE and BE will be unable to communicate. This can take up to six minutes: five minutes for the timer to elapse, plus one minute for the IKE protocol to decide that it needs to establish a new SA. In Exchange 2000, there was no way to fix this, meaning that Microsoft didn’t support the use of IPsec in this configuration. However, in Windows 2003, you can adjust the renegotiation interval down so that reestablishment takes a maximum of two minutes: one minute for the idle timer to expire, plus one minute for IKE renegotiation.

10.5. Enabling SSL Offloading

Problem

You want to use a hardware SSL accelerator in front of your Outlook Web Access server.

Solution

To enable SSL offloading when you are not using forms-based authentication, perform both of the following procedures. If you are using forms-based authentication, you only need to make the registry modification.

Modifying the registry

Log on to the Exchange server that hosts SSL-enabled connections for your users. In a front-end/back-end topology, this will be the front-end server; otherwise, it’ll be the back-end server.
Open the Registry Editor (regedit.exe).
Navigate to:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeWEBOWA
Right-click the OWA subkey and select New→ DWORD Value.
Name the new value SSLOffloaded and give it a value of 1.
Quit the Registry Editor.

Registering the ISAPI filter

Contact Microsoft Product Support and get a copy of ExFeHttpsOnFilter.dll (It’s free, but they don’t make it generally available, so you’ll have to call them and reference MS KB 327800).
Log on to the Exchange server that hosts SSL-enabled connections for your users. In a front-end/back-end topology, this will be the front-end server; otherwise, it’ll be the back-end server.
Copy the DLL to the exchsrvrin directory on the target Exchange server.
Launch the IIS Manager snap-in and expand the Local Computer and Web Sites nodes.
Right-click the Default Web Site entry and select Properties.
Switch to the ISAPI Filters tab and click the Add button.
In the Filter Name field, type ExFeHTTPSOn. In the Executable field, specify the location of the DLL you copied in step 3 and click OK.
If necessary, use the Move up and Move down buttons to make sure that the newly added filter is before the ExchFilt filter.
Restart the IISAdmin and W3SVC services.

Discussion

There are two primary types of SSL acceleration devices. The first are plug-in cards that you put in your server. They provide an interface to the Windows CryptoAPI layer such that CryptoAPI calls made by applications like IIS and Exchange are offloaded to the cards. Examples include the HP/Atalla AXL600L and the nCypher nFast card. You don’t have to do anything special to make these cards work with Exchange. The other type of accelerator is usually built into a hardware IP management device. Examples of this type include the F5 Big-IP line, the Alteon 310, and the Cisco SCA 11000 series. These devices are the ones that require the measures described in the Solution section, at least in some cases. There are three scenarios in which you might be using SSL acceleration in conjunction with Exchange:

SSL passes from the client straight to the front-end server, with no intermediate devices or appliances. In this case, you don’t have to apply the steps above.
SSL passes from the client to an intermediate appliance or device (including the devices described above or an ISA Server computer) that terminates the SSL connection before it reaches the front-end. In that case, client-appliance communications use SSL, but communications from the appliance to the front-end server use plain HTTP. What you do next depends on whether you’re using forms-based authentication (FBA):
- If you are not using FBA, you need to apply the ExFeHTTPSOnFilter filter and apply the SSLOffloaded registry key.
- If you are using FBA, you need only to apply the registry change.
The client’s not using SSL. You shouldn’t use this configuration over the Internet; on corporate networks, it may sometimes be necessary. In that case, you don’t need to make the changes described in this recipe.

These devices can terminate the SSL connection, or they can pass it through directly to the target host. The most common configuration is usually to have the device terminate the session and establish a new one to the target Exchange server, as this facilitates load balancing. In this configuration, though, you have to apply the ExFeHttpsOnFilter trick described in this recipe, or OWA won’t have any idea that SSL was originally in use, so the links it generates will start with http:// and not https://.

These machinations all leave aside the larger question of whether it actually makes sense to buy the first kind of accelerator. Generally, SSL isn’t the bottleneck for front-end servers; the boundary we normally use is that if the server is handling more than 100 concurrent SSL handshakes per minute, it might make sense to buy an accelerator. The handshake is the most resource-intensive component of SSL traffic; once it’s completed, the ongoing encryption of passing traffic causes fairly low overhead.

10.6. Setting Up S/MIME in Outlook

Problem

You want to enroll a user so she can use S/MIME with Exchange Server 2003.

Solution

Using a graphical user interface to set up S/MIME in Outlook

Install or gain access to a certificate authority (CA) that can issue certificates to your users. Chapter 6 of the Exchange Server 2003 Message Security Guide covers this process in detail, as does the Windows Certificate Services documentation included with both Windows 2000 and Windows Server 2003.
Log on to the computer on which you want to enroll in advanced security.
Launch Outlook using the profile that you want to request a certificate.
Request a certificate from your CA. For Windows Certificate Services installations:
1. Open a browser window and go to http://<CAServerName>/certsrv.
2. Click Request a certificate.
3. Click User certificate.
4. Click Submit.
5. If Internet Explorer prompts you to confirm your request, click Yes.
6. Depending on how the CA is configured, your request may be automatically approved, or an administrator may have to approve it. If the request is automatically approved, you’ll see a link labeled Install this certificate. Click it.
7. If Internet Explorer prompts you to confirm that you want to add this certificate to the local computer, click Yes.
Switch to Outlook. From the menu, select Tools→ Options. The Options dialog will appear.
Click the Security tab and click the Settings button. The Change Security Settings dialog will appear as shown in Figure 10-2.
Use the Choose buttons in the Certificates and Algorithms section to choose the certificates you want to use for signing and encryption and click OK.
Click OK.

Figure 10-2. The Change Security Settings dialog from Outlook 2003

Using a graphical user interface to set up S/MIME in Outlook Web Access 2003

Log on to the machine where you want to set up OWA 2003. To use the S/MIME ActiveX control, you’ll need to be on a Windows 2000 or later computer with ActiveX enabled for the domain in which the Exchange server is located.
Use Internet Explorer to log in to OWA 2003.
Click the Options link on the left navigation bar.
Tip
Windows XP Service Pack 2 makes some significant changes to how OWA works. First, you’ll need to tell Internet Explorer to allow pop-ups from your OWA server or you won’t see any calendar reminders, and a number of other features (including many of the shortcut menu commands and the Attachments dialog box) will fail. SP2 also makes some changes to how ActiveX controls are hosted, displayed, and executed; these changes may require you to add a hotfix to your Exchange servers if you wish to use OWA with the S/MIME control on Windows XP SP2 clients. MS KB 883543 for more details.
Scroll down to the E-mail Security options group. If you see the Download button, click it to download the S/MIME control to the computer you’re using. Doing so will cause IE to display a pair of security warning dialogs; accept the warnings and allow the download to continue.
Once the control has been downloaded, run the resulting executable to install the S/MIME control.
Once the control has been installed, the E-mail Security options group will contain checkboxes that let you specify whether new messages should be signed or encrypted by default.
When you create a new message, notice that there are two additional tool icons on the toolbar: one for encrypting and one for signing. These icons won’t work unless and until you install a certificate for the logged-in user, using whatever tools are appropriate for your CA.

Discussion

S/MIME complements other methods of protecting Exchange email, because it alone provides end-to-end protection for the message from the time it’s sent until the recipient decrypts it. This protection includes protection against tampering and eavesdropping in transit and while the message is stored. In contrast, IPsec only provides protection for the message while it’s in transit between servers. However, the implementation footprint of S/MIME is pretty large: you have to have a CA that can issue certificates to your users, and you have to configure individual clients accordingly. This recipe deals only with the latter problem, and then only for the two most prevalent Exchange 2000 and Exchange Server 2003 clients. Table 10-1 shows some common clients and the degree to which they support S/MIME.

Table 10-1. Supported S/MIME clients for Exchange 2000 and Exchange Server 2003

Client name	Access method	Signed?	Encrypted?	Notes
Outlook	MAPI	Yes	Yes	Outlook 2000 SR-1 and later support S/MIME Version 3.
Outlook Web Access 2000	WebDAV	No	No	Can view clear-signed messages; can’t create encrypted or signed messages.
Outlook Web Access 2003	WebDAV	Yes	Yes	Requires that S/MIME ActiveX control be present; requires the user certificate be present on the OWA client machine, making this impractical without use of smartcards or other tokens. Not supported in “basic” OWA mode.
Outlook Express	POP, IMAP	Yes	Yes
Outlook Mobile Access	WebDAV	Clear only	No	OMA can read clear-signed messages only.
Exchange ActiveSync	WebDAV	Clear only	No	EAS can read clear-signed messages only.
Entourage 2004	IMAP, POP, WebDAV	Yes	Yes
Entourage X	IMAP, POP	No	No
Generic POP clients	POP	?	?	Eudora, Thunderbird, and others support S/MIME, but not all clients do.
Generic IMAP clients	IMAP	?	?	Eudora, Thunderbird, and others support S/MIME, but not all clients do.

10.7. Creating a Custom DNS Block List

Problem

You need to create a custom DNS block list (DNSBL) instead of (or in addition to) using a third-party DNSBL service.

Solution

Using a graphical user interface

To create the block list, do the following:

Assemble a list of the IP addresses that you want to block.
Open the DNS Management snap-in (dnsmgmt.msc) using an account that has administrative privileges in your domain.
Expand the server and Forward Lookup Zones objects.
Right-click Forward Lookup Zones and select New Zone. When the New Zone Wizard appears, click Next.
Select Primary zone in the Zone Type wizard page, then click Next.
On the Active Directory Zone Replication Scope page, click Next.
Name the zone and click Next.
On the Dynamic Update page, click the Do not allow dynamic updates radio button and click Next.
Click Finish to create the zone.
Right-click the new zone and select New Domain. When the New DNS Domain dialog box appears, name the domain after the first octet of the first server on your block list. For example, if one of the servers you want to block has an IP address of 1.2.3.4, you’d name this domain 1. Click OK to create the domain.
Right-click the newly created domain and select New Domain; name the new subdomain after the second octet of the host you want to block and click OK.
Repeat step 11, this time using the third octet.
Right-click the third octet’s subdomain and select New Host (A).
In the New Host dialog, enter the fourth octet of the blocked host as the host name, enter an IP address of 127.0.0.1, and click Add Host. Click OK to dismiss the confirmation dialog.
If you want to add additional hosts in the same IP address range as the current host, repeat step 14 for each host you want to add. Click Done when you’ve added all of the hosts in the current subdomain.
Create additional subdomains and hosts as necessary to include all of the IP addresses you gathered in step 1.
Create an Exchange connection filter to use your new DNS block list for spam filtering, as described in Recipe 7.22.

Discussion

The idea behind DNSBLs is simple: when your server gets an inbound piece of mail, it can query a DNSBL server for the IP address of the sending server. If the IP address belongs to a known spammer, to an address block reserved for dial-up users, or some other range of IPs from which legitimate mail is unlikely to originate, the DNSBL server will return an address; if the IP address isn’t on the list, the query will fail. Based on this go/no-go indication, Exchange can then decide whether to drop the connection or to accept the message.

There are several popular and well-maintained DNSBL services such as SpamHaus and SpamCop. Most mail administrators who use DNSBLs use third-party lists, although those at larger sites will often download the zone data and run it on a local nameserver. You are free to create and maintain your own list if you prefer. This gives you a greater degree of control over the contents of the DNSBL, since some third-party services use rather relaxed standards to decide who is spamming. DNSBLs by themselves aren’t a complete anti-spam solution, especially given that a large percentage of current spam is sent by hijacked Windows machines connected to various ISPs; their IP addresses don’t fall into a contiguous block, and there’s little value in banning hundreds or thousands of individual client IPs. DNSBLs are instead useful as an additional protective layer to be relied on after other measures.

Managing a large amount of blocklist data through the GUI can become quickly cumbersome, especially if it changes on a frequent basis. You may want to look into other methods of managing DNS data: direct import of DNS zone files; use of the dnscmd.exe utility to programmatically update data in dynamic DNS zones; or using the MicrosoftDNS_Server, MicrosoftDNS_Zone, and MicrosoftDNS_ResourceRecord WMI classes. Although the details of these methods are out of the scope of this recipe, Matt Larson, Cricket Liu, and Robbie Allen provide a thorough reference to the many facets of running a Windows-based DNS server in their book DNS on Windows Server 2003, also available from O’Reilly.

10.8. Controlling Anonymous Address Resolution

Problem

You want to reduce the possibility of outside parties spoofing sender addresses.

Solution

Using a graphical user interface to control address expansion in Exchange 2000

Open the Registry Editor (regedit.exe).
Navigate to:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeTransport
If the Parameters subkey exists, select it. If not, right-click MSExchangeTransport and select New→ Key.
Each SMTP virtual server has its own subkey under the Parameters key corresponding to its ordinal number. For servers with only 1 SMTP virtual server, this subkey will be named 1. If no key exists for the virtual server that accepts your inbound Internet mail, right-click the Parameters key and select New→ Key to add it.
Right-click the SMTP virtual server key and select New→ DWORD Value to create a new value named ResolveP2. Give it the appropriate flag value:
0x08
Tells Exchange to resolve the From header in incoming mail
0x10
Tells Exchange to resolve the To and CC header fields
0x20
Tells Exchange to resolve the Reply-To field
By default, Exchange will attempt to resolve all these headers, but by changing the flag value you can force it to ignore certain headers.
Quit the Registry Editor.
Stop and restart the SMTP virtual server to which you added this key.

To set the ResolveP2 flag in Exchange Server 2003:

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.
Locate the target server and expand its Protocols container and the SMTP node beneath it.
Right-click the Default SMTP Virtual Server node and select Properties.
Switch to the Access tab and click the Authentication button. The Authentication dialog, shown earlier in Figure 10-1, will appear.
Click the Resolve anonymous E-mail checkbox and click OK.

Discussion

When incoming SMTP mail arrives at an Exchange server, it is sometimes desirable to check SMTP addresses in the headers against the global address list. This allows mail sent from [email protected] to appear as “Paul Robichaux” in the mailboxes of other users in our organization. However, it also allows spoofed mail that claims to be from within the organization to have its headers resolved so that the mail looks more legitimate. The implementation and behavior of this feature varies between Exchange 2000 and Exchange Server 2003.

Exchange 2000: You must add the ResolveP2 registry key but you can control which specific headers it attempts to resolve. This is useful because you might not want some headers resolved. One example: if you send mail from a mailbox that has multiple SMTP addresses, the outbound mail will always have the mailbox display name on it. That means that recipients who originally mailed to one SMTP address can get responses from another, completely different, address.
Exchange Server 2003: For each incoming SMTP message, Exchange Server 2003 tracks whether the message was submitted anonymously or by an authenticated user or connection. Authenticated messages always have their headers resolved; the Resolve anonymous E-mail checkbox described in step 6 controls whether or not resolution occurs on anonymously submitted messages.

Header resolution only applies to messages that are passed into the message store via SMTP. If messages are submitted via SMTP and directly delivered to another system via an SMTP transport, Exchange will not modify the headers. Because the header resolution relies on matching the SMTP address with extended user MAPI properties in Active Directory, the message must first be passed into the information store for resolution to take place.

Remember that the value of this setting applies only to individual SMTP virtual servers. Microsoft recommends that you disallow anonymous resolution on any machine that accepts SMTP traffic from the Internet, so if you want to allow header resolution for some of your messages, you may need to create additional virtual servers.

10.9. Disabling Unnecessary Exchange Services

Problem

You want to minimize the attack surface of your Exchange servers by disabling unnecessary services.

Solution

Using a graphical user interface

Log in to the target Exchange server using an account with administrative privileges.
Open the Services snap-in (services.msc).
Check Table 10-2 for services that you need for your server type (Exchange 2000 or Exchange Server 2003) and role (front- or back-end server).
For each service in the table, verify that its startup type is set appropriately.

Table 10-2. Service settings for Exchange front- and back-end servers

Service name	Short name	Enabled on FE?	Enabled on BE?	Notes
Microsoft Exchange Information Store	MSExchangeIS	Maybe	Yes	The IS is required for servers that serve mailboxes, but it’s also required for SMTP bridgeheads so they can generate and process NDRs.
Microsoft Exchange System Attendant	MSExchangeSA	Maybe	Yes	The SA is required to do any sort of Exchange management. You can disable it on the FE, but you’ll need to reenable it before you can make changes to the server’s ettings via ESM.
IIS Admin Service	IISAdmin	Maybe	Yes	Required if you’re using IMAP, POP, Web, SMTP, NNTP, or well as the routing service; can be disabled otherwise.
FTP Publishing Service	FTPSvc	No	No	Not installed by default on Windows 2003. Don’t ever enable this unless you’re running an FTP server.
World Wide Web Publishing Service	W3SVC	Maybe	Yes	The W3SVC is required for web access via OWA, OMA, or EAS.
HTTP SSL	HTTPFilter	Yes	Yes	This service provides SSL filtering for the W3SVC; its start state should be set to “manual.”
Microsoft Exchange Event	MSExchangeEVent	No	No	This service is only required if you want to run Exchange 5.5 event scripts on your server.
Microsoft Exchange IMAP4	IMAP4SVC	Maybe	No	Only required for servers that allow IMAP access to mailboxes.
Microsoft Exchange Management	MSExchangeMGMT	No	Yes	Required for message tracking and other management functions. Depends on the WMI service.
Microsoft Exchange MTA Stacks	MSExchangeMTA	No	Maybe	The equivalent of the 5.5 MTA; required for X.400 communication with 5.5 servers or X.400 connectors. Must be running to move mailboxes with ESM on Exchange 2000 but not Exchange Server 2003.
Microsoft Exchange POP3	POP3SVC	Maybe	No	Required for servers that offer POP3 mailbox access; off elsewhere.
Microsoft Exchange Routing Engine	RESvc	Maybe	Yes	Handles interserver message routing (in conjunction with SMTP). Required on back-end servers and bridgeheads; unnecessary on nonbridgehead FEs.
Microsoft Exchange Site Replication Service	MSExchangeSRS	No	Maybe	Required for backward compatibility with Exchange 5.5; should be disabled on all servers when running in native Exchange mode.
IPsec Services	PolicyAgent	Yes	Yes	Required for machines that are using IPsec.
RPC Locator	RpcLocator	Yes	Yes	Required for RPC communications with DCs (for logons) and clients.
NTLM Security Support Provider	NTLMSSP	Yes	Yes	Don’t disable this or RPC communications will break.
Simple Mail Transport Protocol (SMTP)	SMTPSvc	Maybe	Yes	SMTP is required on back-end servers to enable interserver message transport. It’s required on FEs that act as SMTP bridgeheads.
Network News Transport Protocol (NNTP)	NNTPSvc	No	No	NNTP is required in three instances: when you’re setting up Exchange, when you’re using NNTP, or when you’re managing public folders with ESM. Unless you’re doing these things, you can turn it off.
Microsoft Search	MSSearch	No	Maybe	Required in order to use full-text mailbox indexing; turn off on nonmailbox servers or if FTI isn’t in use.
Terminal Services	TermService	Maybe	Maybe	Set to manual on servers that you want to be reachable via Terminal Services; disable to prevent remote logon via TS.

Using a command-line interface

Log in to the target Exchange server using an account with administrative privileges.
Check Table 10-2 for services that you need for your server type (Exchange 2000 or Exchange Server 2003) and role (front- or back-end server).

For each service in the table, set its startup type using the sc command with the start flag. You can set the start type to disabled, manual, or automatic. For example, this script will apply the appropriate baseline settings for a front-end Exchange Server 2003 server that’s being used only as an OWA proxy:

Sc start=disabled POP3Svc
Sc start=disabled IMAP4Svc
Sc start=disabled MSExchangeIS
Sc start=disabled MSSearch
Sc start=disabled MSExchangeSRS
Sc start=disabled MSExchangeES
Sc start=disabled MSExchangeMGMT
Sc start=disabled MSExchangeMTA
Sc start=disabled MSExchangeSA
Sc start=automatic RESvc
Sc start=automatic IISAdmin
Sc start=disabled SMTPSvc
Sc start=disabled NNTPSvc
Sc start=manual HTTPFilter
Sc start=automatic W3SVC

For each service in the table, ensure that you’ve started or stopped the service as appropriate. You can do this with the net stop or sc stop commands:
```
Net stop msexchangesa /y
Sc stop IMAP4SVC
```

Discussion

Code that isn’t running can’t be attacked. For that reason, it’s important to turn off unnecessary services on your Exchange servers, particularly those that face the Internet. This can be tricky, since some services are required for nonobvious circumstances. For example, if the Microsoft Exchange Management service isn’t running on a given server, message tracking won’t work on that server. Table 10-2 lists the key Windows and Exchange services whose state you need to control on your front- and back-end servers.

This list isn’t complete, of course, since there are many other Windows services that implement various features. However, Windows 2003 does a good job of disabling unneeded services, so in the table I’ve included two types of services: those provided by Exchange and those on which Exchange depends. For specific guidance on what a given Windows service does, you should consult the Threats and Countermeasures Guide for Windows 2003 or the Windows 2000 documentation. You should also consult the documentation for any Exchange add-ons; they may introduce additional dependencies. In general, Exchange back-ends require most of the Exchange services to be set to start automatically. In particular, the system attendant, information store, and routing engine services are required, although none of these is necessarily required on a front-end server.

You can make these settings changes in three ways: manually via the GUI, automatically via a script that uses the sc command to set the service start state, or via a security template applied as part of a GPO. Of these three, the last route is the best, because the GPO can be configured so that an administrator cannot easily override the start state defined in the policy. Of course, this makes it harder to turn on services when you have a legitimate reason to do so, and it also requires that you create group policy objects and apply them to your Exchange servers. This process is described in great detail in the “Hardening Exchange 2003 Servers” section of the Exchange Server 2003 Security Hardening Guide.

10.10. Setting Up RPC over HTTPS

Problem

You want to enable RPC tunneling over HTTPS so that your Outlook 2003 users can use Outlook directly against your servers.

Solution

Setting up RPC over HTTPS is easier in Exchange Server 2003 SP1 than it was in the original release version, but it’s still a reasonably involved task that requires you to know a good bit about your Exchange topology, and to understand the underlying mechanics. There are three basic steps:

Setting up an RPC-over-HTTP proxy. This step requires a Windows Server 2003 computer, on which the proxy runs; the proxy’s job is to disassemble incoming HTTP packets that contain RPC traffic and convert them into conventional RPC traffic, then reverse the process for reply packets.
Configuring the Exchange front-end servers. This process is very simple, requiring nothing more than clicking a radio button; however, it must be done separately for each Exchange FE.
Configuring the Exchange back-end servers. This is also a matter of a single click of a radio button.

Using a graphical user interface

To install the RPC-over-HTTP proxy, do the following:

Log in to the front-end server using an account with Windows administrative privileges.
From the Control Panel, open the Add or Remove Programs applet.
Click Add/Remove Windows Components.
Select Networking Services and click the Details button.
Ensure that the RPC over HTTP Proxy box is checked and click OK.
Click Next (you may need to pop in your Windows Server 2003 CD during the install process).

To enable RPC-over-HTTP on an Exchange front-end server, do the following:

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.
Open the Properties dialog for the front-end server you’re configuring and switch to the RPC-HTTP tab.
Select the RPC-HTTP front-end server radio button and click OK.
You’ll see a dialog warning you that SSL is required for use with RPC-over-HTTP; click OK to close it.
Repeat steps 1-5 for each additional front-end server that you want to accept RPC-over-HTTP requests.

To configure an Exchange back-end server, do the following:

Log on to your Exchange server using an account that has Exchange administrative privileges.
Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.
Open the properties dialog for the back-end server you want to configure and switch to the RPC-HTTP tab.
Select the RPC-HTTP back-end server radio button and click OK.
If you see a warning dialog telling you that you don’t have any RPC-HTTP front-end proxies, click OK to close it.
If you’re configuring a back-end server that also happens to be a domain controller, you’ll see a warning dialog that tells you that the ports aren’t configured right (see Figure 10-3). Click OK to configure the ports automatically, but be forewarned: you’ll need to reboot your server before the changes take effect.
Repeat steps 1-6 for each additional back-end server you want to configure.

Figure 10-3. The warning dialog produced when you enable RPC-over-HTTP on a domain controller

To configure SSL offloading for the front-end, do the following:

Log on to the RPC proxy server (which may be your Exchange front-end, or another Windows Server 2003 computer) using an account with administrative privileges.
Open the Registry Editor (regedit.exe).
Navigate to HKEY_LOCAL_MACHINE SoftwareMicrosoftRpcRpcProxy.
Right-click on RpcProxy and select New→ DWORD to add a new DWORD value named AllowAnonymous.
In the right pane, right-click the AllowAnonymous entry and select Modify.
In the Value data field, type 1 and click OK.
Quit the Registry Editor.
Use the Services snap-in or command line to stop and restart the World Wide Web Publishing Service (w3svc).

To configure a single-server Exchange Server 2003 organization, do the following:

Log in to your Exchange server and follow the previous steps for configuring an Exchange back-end server.
Open the IIS Manager snap-in (%SystemRoot%system32inetsrviis.msc).
Locate and expand the target server’s Default Web Site object, then right-click the RPC virtual directory and select Properties.
Switch to the Directory Security tab and click the Edit button in the Authentication and access control group.
Clear the Enable anonymous access checkbox; set the Basic authentication (password is sent in clear text) and Integrated Windows authentication checkboxes. Click OK.
Click OK.
Open the Registry Editor (regedit.exe)
Navigate to HKEY_LOCAL_MACHINE SoftwareMicrosoftRpcRpcProxy.
Right-click the ValidPorts value and select Modify. You’ll need to change its value to open ports 6001 and 6004 to your server, for which you’ll need the NetBIOS and fully qualified domain names of your server. Format the string like this:
```
                        <serverNetBIOS>:6001;<serverFQDN>:6001;<serverNetBIOS>:6004;<serverFQDN>:6004;
```
where <serverNetBIOS> is the NetBIOS name of your Exchange server and <serverFQDN> is the full DNS name (e.g., someserver.oreilly.com).

If your Exchange back-end server is also a global catalog server, you have to force the directory service to use the correct TCP port for queries. To do so, follow these steps:

Open the Registry Editor (regedit.exe).
Navigate to HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters.
Right-click on Parameters and select New→ Multi String Value. Name the new value NSPI interface protocol sequences.
Right-click the new NSPI interface protocol sequences value and select Modify. Change the value to contain ncacn_http:6004.
Quit the Registry Editor and restart the server.

Discussion

One of the biggest new features of Exchange Server 2003 is its ability to work with Outlook 2003 to tunnel remote procedure call (RPC) traffic inside of ordinary-looking HTTP packets. This might not seem like a big deal, but it is. Microsoft has long recommended against allowing random Internet clients to send RPCs directly into your network—a number of serious vulnerabilities in the Windows NT RPC stack led to this policy, and it’s very rare to find exceptions. That means that Outlook, which uses RPCs to exchange MAPI data with the server, needs an unobstructed path between the Outlook machine and the Exchange server. Previously, there were three primary ways to accomplish this: allow raw RPC traffic from the Internet, use ISA Server to publish the RPC interfaces, or allow Outlook users to establish VPN connections to the corporate network. This new feature adds a fourth way: when enabled, Outlook 2003 takes its RPC requests and encapsulates them in an HTTP packet, which it then sends using HTTP (preferably with SSL) to an RPC proxy server. This server breaks apart the HTTP packet and redirects the RPC requests to the Exchange back-end server, returning any results to the client in an encapsulated HTTP packet.

The advantages of this are obvious: it allows the Outlook client to connect without needing a VPN (and thus without any special configuration or, worse, proprietary VPN clients on the client machine), but it doesn’t allow raw RPC traffic from the Internet. If you wish, you can use ISA Server to perform application-level inspection of the RPC packets as they come in, but that’s not mandatory. However, there are some prerequisites: to use RPC-over-HTTP, you must have Exchange Server 2003 running on Windows Server 2003, and all GCs that Exchange or the clients will talk to must also be running Windows Server 2003. Outlook 2003, running on Windows XP SP1 or later, is required as the client.

Overall, the configuration and setup process for RPC-over-HTTP is fairly straightforward; it was greatly improved with the release of SP1, which introduced the RPC-HTTP tab in the server properties dialog. One significant speed bump is that the server SSL certificate installed on the RPC proxy must match the common name that the client uses to connect. Let’s say you’ve configured a client to connect to exchange.robichaux.net, and that your RPC proxy is named spiderman.robichaux.net and has a certificate by that name. Because the names don’t match, the SSL handshake will fail (as described in MS KB 822594). To fix this, either change the RPC proxy name specified on the Outlook client or get a new certificate for the RPC proxy itself.

What about SSL offloading? This term is a little misleading in this context. It would probably be more proper to talk about SSL termination, since the steps in this recipe are required when you want to terminate an inbound RPC-over-HTTPS connection at an ISA server (or other firewall), then pass the unencrypted traffic to the RPC proxy server, then to the back-end server. In most configurations, it’s easier to either allow SSL bridging so that the proxy sees an SSL connection or to put the proxy service on the firewall machine so that the termination happens at the proxy.

10.11. Setting Up TLS Security for SMTP

Problem

You want to enable the use of Transport Layer Security (TLS) encryption for your SMTP traffic.

Solution

Using a graphical user interface

To enable TLS for an SMTP virtual server, do the following:

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.
Expand the target server’s Protocols node and expand its SMTP node.
Right-click the SMTP virtual server on which you want to use TLS and select Properties.
Click the Access tab. If the Communications button is enabled, click it. If it’s not enabled, you must first install a certificate. To do so, perform the following steps:
1. Click the Certificate button. The Web Server Certificate Wizard will appear; click Next.
2. On the Server Certificate page, indicate whether you want to request a new certificate or use an existing one. If you already have an SSL certificate installed for use with OWA, you can reuse it by selecting the Assign an existing certificate button. (If you need to request a new certificate, refer to the instructions provided by your certificate authority; we won’t cover the process here.) Click Next.
3. In the Available Certificates page, select the certificate you’re using for SSL and click Next.
4. Click Next on the summary page, then click Finish to dismiss the certificate wizard.
5. Click the Communications button.
Click the Require secure channel checkbox. For added security, you should also click the Require 128-bit encryption checkbox. Click OK.
Click OK.

To enable TLS for an SMTP connector, do the following:

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate routing group container.
Find the target routing group and expand its Connectors node.
Right-click the target connector and select Properties.
Switch to the Advanced tab and click the Outbound Security button.
Check the TLS encryption check box and click OK.
Click OK.

Discussion

SMTP itself doesn’t include any provision for encrypting traffic, but the Internet Engineering Task Force (IETF) has approved a number of extensions to SMTP, including the STARTTLS verb (described in IETF RFC 2487). STARTTLS is used for one end of an SMTP connection to signal the other end that it can handle encrypting the channel. Some SMTP servers support it, and some do not; in addition, many mail user agents (including Outlook, Outlook Express, Eudora, and various PDA mailers) support using STARTTLS to secure email between client and server. TLS is especially useful in conjunction with authenticated SMTP mechanisms that transmit credentials in the clear (see Recipe 10.2); the combination is often necessary when using SMTP authentication with non-Microsoft SMTP implementations.

The problem with TLS in Exchange is that Exchange doesn’t support opportunistic TLS. Most UNIX TLS implementations can be configured to try to negotiate a TLS session first, then to accept mail anyway if the TLS negotiation fails. Exchange can’t do this. If you enable TLS at the Exchange virtual server level, it will refuse to accept any mail from senders who aren’t using TLS. That means that if you enable this on your default virtual server, you’ll start throwing away lots of inbound mail from servers that are not using TLS. There’s no way to make Exchange use fully opportunistic TLS. For that reason, Microsoft recommends that you enable TLS only for specific domains that you know can respond in kind through the use of SMTP connectors. You do this by setting up SMTP connectors directly to those domains you wish to use TLS with and enable TLS for those connectors only. For example, you might set up a connector just for traffic to your company’s law firm, then force TLS usage on that connector. Result: all SMTP mail between you and your lawyers would be encrypted.

You can force Exchange to use TLS for all outbound mail on a particular virtual server. This might seem to have the desired effect of protecting your outbound mail from eavesdropping; however, if you enable this option, Exchange will still refuse to communicate with any servers that don’t have TLS enabled, so outbound mail to those destinations will stack up in your outbound queues. Again, the answer is to use SMTP connectors to specify those domains where Exchange should use TLS.

10.12. Changing Server Banners

Problem

You want to change the service connection banner displayed to new SMTP, IMAP, or POP sessions.

Solution

Using a graphical user interface

The following steps describe how to use MetaEdit on Windows 2000 Server to change the SMTP, IMAP, or POP banners:

Log in to the target Exchange server as an administrator.
Download MetaEdit 2.2 from the Microsoft Download Center (http://download.microsoft.com/download/iis50/Utility/5.0/NT45/EN-US/MtaEdt22.exe) and install it.
Open MetaEdit and open the Lm< ServiceName> <VirtualServerNumber> node, where <ServiceName> is either imap4svc, pop3svc, or smtpsvc.
From the Edit menu, select New→ String.
In the ID field, select Other and enter the banner ID (36907 for SMTP, 41661 for POP, and 49884 for IMAP).
In the Data field, type the new banner entry.
Close MetaEdit.
Stop and restart the service whose banner you modified.

The following steps describe how to use MetaBase Explorer on Windows Server 2003 to change the SMTP service banner:

Log in to the target server as an administrator.
Install the IIS 6.0 Resource Kit on the Exchange Server 2003 server (get it from:
http://download.microsoft.com/download/7/8/2/782c25d3-0f90-4619-ba36-f0d8f351d398/iis60rkt.exe
if necessary).
Open the MetaBase Explorer.
Expand the LM and SmtpSvc nodes, right-click the number corresponding to the SMTP virtual server instance you are going to modify, and select New→ String Record.
In the Record Name or Identifier field, select ConnectResponse, click OK, and double-click the new identifier that was just created.
In the Value Data field, type the new banner entry.
Close MetaBase Explorer.
Stop and restart the service whose banner you changed.

Using a command line

Log in to the target Exchange server as an administrator.
Use the net stop command to stop the service whose banner you want to modify (see Table 10-2 for service names). For example, to stop the IMAP service, use the following command:
```
> net stop imap4svc
```
Use the smtpmd command (only available from PSS) to set the new banner:
```
> smtpmd SET -path <svcName>/<svcInstance> -dtype STRING -prop <propertyID> -value <banner>
```
where <svcName> is the name of the service (pop3svc, imap4svc, or smtpsvc), <svcInstance> is the virtual server instance number (the first virtual server is 1, the second is 2, and so on), <propertyID> is the ID of the string for that service’s banner (36097 for SMTP, 49884 for IMAP, or 41661 for POP), and <banner> is the text you want to appear in the banner (surround it in quotes if it contains spaces).
Use the net start command to restart the stopped service.

Discussion

The usual rationale for changing the SMTP banner is to prevent advertising the fact that your server is running Exchange; by stripping this revealing information, so the theory goes, potential attackers will not realize they have connected to an Exchange server and will not try any Exchange-specific attacks they may know about.

This theory sounds great right up until the time you connect your modified server to the Internet. What really happens is that the attacker replies to the ESMTP banner with a properly formatted EHLO response; why not, since they are going to need to do so no matter which attack they wish to launch? They then see the list of extended SMTP verbs supported by the server and immediately realize they are dealing with Exchange thanks to the Exchange-specific ESMTP features. Even more commonly, they are not looking for software-specific vulnerabilities, but configuration errors that will allow them to relay messages through your server; they do not care what software you are running, only whether you have properly closed down relay access. This rationale is less applicable to the POP and IMAP services because they don’t implement any significant Exchange-specific features.

Because the Exchange SMTP, IMAP, and POP services extend the underlying IIS services, this recipe depends on the version of Windows on your Exchange server, not the version of Exchange. Although you cannot install Exchange 2000 on Windows Server 2003, you can run Exchange Server 2003 on Windows 2000 (see Chapter 1 for more details).

By default, the SMTP banner is a string concatenated from the following elements:

The SMTP result code 220 indicating the beginning of the session
The fully qualified domain name of the server
The string “Microsoft ESMTP MAIL Service, Version:”
The version of the ESMTP mail service
The string “ready at”
The date and time

For example:

220 host.fdqn.tld Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 
ready at  Wed, 8 Dec 2004 22:52:28 -0800

When you change the banner property, Exchange will still display the SMTP result code, the FQDN, and the date/time stamp. Setting the ConnectResponse property to a value of “ESMTP This space for rent” would thus produce:

220 host.fdqn.tld ESMTP This space for rent Thu, 9 Dec 2004 00:52:01 -0800

Whatever connection string you use, be sure to include the string ESMTP in it or else you may disable Extended SMTP functionality on connections with other systems. Some SMTP implantations will not assume the presence of Extended SMTP functionality unless they see the string ESMTP in the initial banner; without it, they will not send an EHLO on the initial connection. This behavior is based on an unwritten rule that many early ESMTP implementations used, though it was never codified in any RFC.

MetaEdit was originally part of the IIS 4.0 Resource Kit. The latest version, 2.2, works on both Windows NT 4.0 and Windows 2000 Server, but will not work on Windows Server 2003 due to the comprehensive changes in the metabase for IIS 6.0.

Editing the metabase for IIS 6.0 is a bit easier. You can use the MetaBase Explorer utility, also part of the appropriate resource kit, or you can take advantage of the ability to directly edit the metabase in XML form. While this feature permits easier scripting capabilities, it is outside the scope of this book. Microsoft provides an example of this functionality in Chapter 6 of the Exchange Server 2003 Technical Reference Guide.

Table of Contents for 10. Exchange Security

Create new playlist

Sign In

Sign Up

Chapter 10. Exchange Security

Introduction

Where to Learn More

10.1. Scanning Exchange Servers for Security Patches

Problem

Solution

Using a graphical user interface

Using a command-line interface:

Discussion

See Also

10.2. Securing SMTP Authentication

Problem

Solution

Using a graphical user interface

Discussion

See Also

10.3. Enabling IPsec Between Front- and Back-End Servers

Problem

Solution

Using a graphical user interface

Using a command-line interface

Discussion

See Also

10.4. Enabling IPsec on an Exchange Server 2003 Cluster

Problem

Solution

Using a graphical user interface

Using the command line

Discussion

See Also

10.5. Enabling SSL Offloading

Problem

Solution

Modifying the registry

Registering the ISAPI filter

Discussion

See Also

10.6. Setting Up S/MIME in Outlook

Problem

Solution

Using a graphical user interface to set up S/MIME in Outlook

Using a graphical user interface to set up S/MIME in Outlook Web Access 2003

Tip

Discussion

See Also

10.7. Creating a Custom DNS Block List

Problem

Solution

Using a graphical user interface

Discussion

See Also

10.8. Controlling Anonymous Address Resolution

Problem

Solution

Using a graphical user interface to control address expansion in Exchange 2000

To set the ResolveP2 flag in Exchange Server 2003:

Discussion

See Also

10.9. Disabling Unnecessary Exchange Services

Problem

Solution

Using a graphical user interface

Using a command-line interface

Discussion

See Also

10.10. Setting Up RPC over HTTPS

Problem

Solution

Using a graphical user interface

Discussion

See Also

10.11. Setting Up TLS Security for SMTP

Problem

Solution

Using a graphical user interface

Discussion

Table of Contents for
10. Exchange Security