The Exchange 5.5 Security Check

For many organizations, Exchange Server 5.5 and Windows NT 4.0 continue to offer reliable service. Such organizations might see few compelling reasons to upgrade, and as a result, you might see Exchange 5.5 in service for a couple more years. Unfortunately, when the time comes to tighten security, many of these Exchange servers sit neglected. Let's review some practical advice for tightening security when you run Exchange 5.5 on NT 4.0. Specifically, let's discuss how to keep up with the latest service packs, secure Windows, lock down Microsoft IIS and Microsoft Outlook Web Access (OWA), enable Secure Sockets Layer (SSL), enable auditing, and instigate general and client-side security measures. (For information about setting up and maintaining Exchange 5.5 on NT 4.0, see "The Exchange 5.5 Reality Check," February 2003, http://www.exchangeadmin.com, InstantDoc ID 27483.)

As with any changes or updates, don't apply all fixes and security-related changes at once. Start with the OS updates, then wait a few days before applying the Exchange 5.5 updates. After a few more days, you can make the security-related changes. When you do make changes, make sure that you understand what you've done and how to reverse the process if necessary.

Service Packs
Your first line of defense when securing any computer is to install the most recent service packs and security fixes. This step entails applying updates to all applications running on your server, but most important the OS, IIS, Microsoft Internet Explorer (IE), and antivirus software. Be sure to check for any interdependencies and potential conflicts between updates you install and your antivirus software.

When you apply patches, the starting point is the OS. If you haven't already, install NT 4.0 Service Pack 6a (SP6a) and the SP6a Security Rollup Package 1 (SRP1), which the Microsoft article "Post-Windows NT 4.0 Service Pack 6a Security Rollup Package (SRP—http://support.microsoft.com/?kbid=299444) documents. Microsoft has released several hotfixes that fix security problems, buffer overflows, and other vulnerabilities since releasing NT 4.0 SP6a SRP1. You can find these hotfixes at the Microsoft Web site at http://www.microsoft.com/downloads.

When you apply service packs and fixes, go ahead and upgrade the server's copy of IE to IE 6.0 SP1 or IE 5.5 SP2. You can then run Microsoft Baseline Security Analyzer (MBSA) 1.1, which replaces HFNetChk, to determine whether you're missing hotfixes. For information about MBSA, see the Microsoft article "Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool Is Available" (http://support.microsoft.com/?kbid=303215). Apply any hotfixes that the tool recommends, especially any that relate to security or buffer overruns.

Next, make sure you update your Exchange server with the latest fixes and updates. The latest service pack for Exchange 5.5 is SP4. Since releasing SP4, Microsoft has issued several updates that you should apply. Web Table 1 (http://www.exchangeadministrator.com, InstantDoc ID 37532) lists these updates and the Microsoft articles you should refer to for more information. I suggest that you apply these fixes in the order that the table presents them.

Windows Security
Exchange is only as secure as the platform on which it runs. Because NT 4.0 isn't known for its tight security out of the box, I recommend that you take the following steps:

• Practice good physical security. If someone with malicious intent can gain physical access to your Exchange server, your data is vulnerable.
• Periodically change the Exchange service account password. Ensure that this password is strong. A common misconception is that this account must be a member of the Administrators or Domain Administrators groups. In fact, the Exchange service account must be a member of the Administrators group only if you use SSL with the Internet Mail Service (IMS). If you have multiple servers, reboot them after you change the service account password.
• Don't use an administrator ac-count as the service account. To maximize security, use another account, such as ExchService, as the service account. (For more information about changing the service account, see the Microsoft articles "XADM: How To Change the Service Account" at http://support.microsoft.com/?kbid=152808 and "How to Change the Exchange Server 5.5 Service Account" at http://support.microsoft.com/support/exchange/content/whitepapers/changingserviceaccount.doc.)
• Disable guest accounts to limit anonymous access.
• Confirm that strong passwords are in place for all administrator, Exchange administrator, and operator accounts. Also check local accounts on member servers; the local SAM database on member servers is often vulnerable. I frequently find blank administrator passwords and enabled guest accounts on member servers. To further protect the SAM database from offline hacking, implement Syskey. (For more information about Syskey, see the Microsoft article "Windows NT System Key Permits Strong Encryption of the SAM" at http://support.microsoft.com/?kbid=143475.)
• Require all domain users to use passwords of a minimum length and complexity. (For more information about enforcing these guidelines, see the Microsoft article "HOWTO: Password Change Filtering & Notification in Windows NT" at http://support.microsoft.com/?kbid=151082.)
• Use NTFS on all server hard disks.
• Don't install Outlook or Outlook Express on the Exchange console.
• Restrict anonymous access to the NT 4.0 server by adding the value RestrictAnonymous of type REG_DWORD to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey; set the value to 1.
• Restrict anonymous access to the registry.
• Remove the Everyone group's permissions to the Add-ins, Address, connect$, Resources, and tracking.log folders, which Exchange 5.5 creates when you install the software. Limit access to these folders to the administrator and Exchange administrator accounts.

Another quick way to further secure Windows computers is to disable unnecessary services. Take care when you disable services because determining which services are unnecessary isn't always easy. Web Table 2 lists some of the NT 4.0 and Exchange 5.5 services that are often installed by default and under which circumstances you can safely disable them.

Microsoft publishes several checklists that can help you secure NT 4.0. These checklists are available at the Microsoft Web site at http://www.microsoft.com/security—click the IT Professionals (TechNet) link. While you're there, sign up for Microsoft's Security Notification Service so that you can stay informed about crucial fixes.

IIS and OWA Security
Exchange 5.5's most significant security vulnerabilities result from security lapses in IIS and OWA. OWA is simply an application that runs on top of IIS and converts HTTP requests from clients to Messaging API (MAPI) requests, which it passes to Exchange servers. Consequently, any vulnerability that affects IIS affects OWA (and possibly Exchange). The most recent Windows and IIS service packs address most IIS-related problems but don't render IIS completely secure.

The IIS Lockdown Wizard can help you with the onerous task of securing IIS. This tool prompts you for the roles that your IIS server assumes, then removes unnecessary features. Make sure you're running the latest version of the tool (as of this writing, version 2.1). To download the tool and view the documentation, visit the Microsoft Download Center at http://www.microsoft.com/downloads. Run iislockd.exe and accept the license agreement, and you'll see the Select Server Template dialog box.

I recommend that you select the View Template Settings check box so that you can see the configuration changes that take place. If this server functions as more than just an OWA server, you must make absolutely sure that you know each of the roles that it performs. The IIS Lockdown Wizard disables permission for anything it deems unnecessary for the role you select on the Select Server Template screen.

The IIS Lockdown Wizard also denies anonymous Web users permission to run pesky command-line programs such as cmd.exe, ftp.exe, rexec.exe, and rsh.exe. Finally, the wizard installs a filter called URLScan on the IIS server. This filter scans, blocks, and logs inbound URLs that are malformed or have characters that don't belong in URLs. If you make a mistake that brings your Web server down, simply run the IIS Lockdown Wizard a second time, and it will reverse any configuration changes it made during the first pass. (For more information about the IIS Lockdown tool and URLScan, see the Microsoft article "HOW TO: Install and Use the IIS Lockdown Wizard" at http://support.microsoft.com/?kbid=325864.)

OWA and SSL
If you use OWA without SSL, you're exposing email information and probably also usernames and passwords. If your OWA server runs on a member server, usernames and passwords use Basic Authentication to travel to the server. Basic Authentication is extremely simple to decode, even for a novice network-analyzer user.

Before you can enable SSL, you must obtain a certificate for your Web server. Organizations such as Thawte and Comodo issue inexpensive Web server certificates that IE trusts.

To enable SSL on the IIS server that supports OWA, open the Internet Services Manager (ISM) console, right-click the Default Web Site, then choose Properties. On the Directory Security tab, click Key Manager. From the Key Manager, which Figure 1 shows, you can create a certificate request for not only HTTP but also POP3, Lightweight Directory Access Protocol (LDAP), Network News Transfer Protocol (NNTP), IMAP4, and SMTP. To launch the Key Manager, run keyring.exe from a command line.

Let's walk through the steps you must take to create a certificate request. For this example, we'll create a certificate request file for a Web server whose Fully Qualified Domain Name (FQDN) is http://owa.steamventsurfing.com. You must know the FQDN URL before you can make a certificate request.

1. Right-click WWW and choose Create New Key.
2. Enter the name of a file that will store the certificate request, then click Next.
3. Enter a name for this particular key request, choose a password, then select a bit length (e.g., 1024 bits is adequate) for the public and private keys. Remember the password—you'll need it when you install the certificate. Click Next to continue.
4. Enter your organization name, an organization unit (OU) name, and the common name of the server. The common name is the OWA server's FQDN. If you don't enter this name correctly, users will receive a warning each time they connect to this server through HTTP Secure (HTTPS). Click Next.
5. Specify the country, state or province, and city or locality for your organization, then click Next.
6. Provide a contact name, an email address, and a phone number. The Certificate Authority (CA) uses this information to contact you, if necessary; this information doesn't appear in the actual certificate. Click Next, then click Finish.
7. Send this certificate request file to a CA, which will create and sign the certificate. The CA will send you a .cer file that contains your certificate.
8. Using Key Manager, right-click the key request name under the WWW protocol (this name should have a key icon with a red line through it). Choose Install Key Certificate, then highlight the certificate file that your CA returned to you. Click Open.
9. Enter the password that you created in Step 3, then click OK.
10. On the Server Bindings property page, select the IP addresses that will use this key or select Any Unassigned. Click OK.
11. The certificate is now installed. Close the Key Manager. In the Commit all changes now dialog box, click Yes.

Next, consider whether to require SSL. With a certificate installed, the Key Manager button on the Web page's Directory Security dialog box changes to an Edit button. Click Edit to see the Secure Communications dialog box, which Figure 2 shows. From here, you can require a Secure Channel, and you can click Encryption Settings and require that browsers support 128-bit encryption. (If you're going to require encryption, you might as well require good encryption.) For more information about SSL and Exchange, see "Secure Client Communications with SSL," October 2001, http://www.exchangeadmin.com, InstantDoc ID 22153.

Auditing and Logging
Many organizations regret not enabling logging sooner. You don't realize just how important audit logs are until you need them. A good starting point is to make sure that you configure an NT Audit Policy for your member servers and domain controllers (DCs). Figure 3 shows the basic auditing that I recommend enabling. If you're concerned that the audit-log files might grow too large, you can choose to audit only the Failure events. To configure the Audit Policy, use the User Manager on member servers or User Manager for Domains for member servers.

Enable IIS logging on all IIS servers that support OWA. To enable IIS logging, open the Web Site property page for the Default Web Site. Select the Enable Logging check box, then choose the W3C Extended Log File Format for the Active log format. Click Properties, then click the Extended Properties tab. I recommend that you select the following options at a minimum:

• Date and Time
• Client IP Address
• User Name
• Method—specifies the HTTP command used (e.g., GET, POST)
• URI Stem—the resource that the client requests
• Http Status—HTTP error codes; codes 200 to 299 indicate success, codes 400 to 599 indicate errors (see http://www.w3.org/protocols/http/htresp.html for more information about these codes)
• User Agent—indicates the browser types and versions that access your IIS server

Next, I recommend that you enable several categories of diagnostic logging for each Exchange server. You can find all diagnostic logging categories on the Diagnostics Logging property page for each server. Be careful not to enable too many diagnostics logging categories because you can adversely affect performance and log more information than you can sift through each day.

Enabling logging isn't the real challenge—reviewing the log files is. So what should you look for? Web Table 3 shows some of the events that might signal various problems.

General Procedures
You can take several steps to make Exchange 5.5 more secure. One often overlooked vulnerability is that the Internet protocols (i.e., HTTP, IMAP4, LDAP, NNTP, and POP3) are all enabled by default. You can disable these protocols for an entire site or on a per-server basis (except HTTP, which you can configure for the entire site only). You configure these protocols for each site or server in the Protocols container. To disable a protocol, open the protocol's General property page and clear the Enable Protocol check box.

Next, consider enabling message tracking and keeping the tracking logs for 15 to 30 days. Message tracking can help you track the source of a message and can be useful when investigating stalled messages or analyzing message-system use. To enable message tracking, open the site Configuration container on the General property page for the Information Store Site Configuration and the Message Transfer Agent (MTA) Site Configuration, then select the Enable Message Tracking check box. If you use IMS, you enable message tracking on the Internet Mail property page. You configure log retention at the server level on the General property page of the System Attendant properties page.

If you enable message tracking, make sure that you have enough hard disk space to hold the logs; a busy server can easily generate 50MB to 75MB of logging per day. Protect these log files from prying eyes because they contain information about your users. If you want to load these logs into a database or use a text-processing system to farm information from them, see the Microsoft article "XADM: Tracking Log Field Descriptions" (http://support.microsoft.com/
?kbid=173280) for information about the log file format and "XADM: Exchange 5.0 and 5.5 Tracking Log Event Numbers" (http://support.microsoft
.com/?kbid=173364) for information about the event numbers in these logs. Several third-party vendors, including PROMODAG and NetIQ, offer reporting tools for these logs.

To further secure your Exchange server, take the following steps:

• Reduce the size of inbound and outbound SMTP messages by configuring an IMS maximum message size limit. Typical limits for externally exposed mail on IMS range from 2MB to 20MB. Consider your organization's messaging requirements before imposing these limits.
• Reduce the size of the messages that your Exchange servers handle internally between Exchange servers. Limit the maximum message size that the MTA accommodates. Typical message size limits for the MTA range from 5MB to 20MB.
• Never assign a mailbox to administrative or operator accounts.
• Limit the maximum number of recipients per message. (See the Microsoft article "Limiting the Number of Recipients of a Message" at http://support.microsoft.com/?kbid=126497 for more information about this procedure.)
• Don't allow anonymous LDAP, NNTP, IMAP4, or HTTP logons.

Client-Side Security
Today, Denial of Service (DoS) outages that result from virus outbreaks are the most common source of Exchange problems that I deal with. You should have a good antivirus strategy in place for your Exchange server and your clients. Another good security precaution is to install the Outlook Email Security Update for Outlook 2000 and Outlook 98. Such updates can help reduce the likelihood that any virus a user encounters will propagate throughout your organization. Microsoft included the fixes from these updates with Outlook 2002; however, no such update is available for Outlook 97. For more information about these security updates, visit the Outlook and Exchange Solutions Center at http://www.slipstick.com/outlook/esecup.htm.

If your users are concerned about message authenticity and security, consider using Secure MIME (S/MIME) to implement message encryption and digital signatures. If you support just a few clients, I recommend that you obtain email certificates from a third-party provider. Several CAs, including Thawte and Comodo, offer free email certificates.

A full discussion of deploying a Windows 2000 public key infrastructure (PKI) and the Exchange Key Management Server is beyond the scope of this article. To learn more about operating your own Exchange CA, see the Microsoft white paper "Windows 2000 Server and Key Management Server Interoperability" (http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms.doc).

Batten Down the Hatches
For many of us, Exchange 5.5 will continue to be a fact of life. Making Exchange 5.5 and NT 4.0 operate securely will continue to be a challenge. If you implement good security practices, solidify the OS, and place the proper restrictions on your users, Exchange 5.5 can continue to deliver reliable and secure messaging service for years to come.