Exchange Server 2003 Security

For several years, intruders have directed many attacks at Microsoft software, including Microsoft IIS, Internet Explorer (IE), and the Outlook and Outlook Express mail clients. Microsoft Exchange 2000 Server adopted SMTP as its basic messaging transport and uses IIS's IP stacks. As a result, attacks on IIS can potentially affect Exchange installations, including Exchange Server 2003.

In 2001, Microsoft started a big security push known as the Trustworthy Computing initiative. Windows Server 2003 is the company's first enterprise OS to benefit from this initiative. As a result of the Trustworthy Computing initiative, Microsoft has upgraded many components that will improve the overall security of Exchange 2003 as well, including changes that the company made to Windows 2003 and Internet Information Services (IIS) 6.0. Bear in mind that Exchange 2003 can run on Windows 2000 Service Pack 3 (SP3) and use IIS 5.0, but if you want to take advantage of many of the new security features, you must run Exchange 2003 on Windows 2003 and use IIS 6.0.

By examining some of the more important new Exchange 2003 security features, such as spam protection, Outlook Web Access (OWA) security, communications security, and other security enhancements, you can provide a more secure enterprise-messaging infrastructure. Many of these features require that you install Outlook 2003 and use the latest version of Microsoft's browser, IE 6.0, which comes bundled with Windows 2003 and Windows XP.

One of the cornerstone principles of the Trustworthy Computing initiative is "secure by default," which means that the default installation of any piece of Microsoft software will be locked down. Let's review this principle as it applies to Windows 2003, Exchange 2003, and IIS 6.0.

Secure by Default in Windows 2003
Secure by default is based on more restrictive default access control settings and new features that honor the fundamental security principle of least privilege. The latter principle means that you provide users or services with only the permissions they need to do their job.

By default, every Windows 2003 installation enables a strong-password policy, which means the OS remembers a user's past 24 passwords; passwords can have a minimum age of 1 day and a maximum age of 42 days, must be at least seven characters long, and should adhere to a set of complex requirements (e.g., contain at least one lowercase, one uppercase, and one numeric character). This strong-password feature clearly affects Exchange users who log on to their mailboxes by using a Windows account.

When you open IE in Windows 2003, you'll notice that the IE Enhanced Security Configuration is enabled. This feature locks down the IE security zone settings. The most notable effect of this IE lockdown is that the Internet Zone gets the same security settings as the Restricted Sites Zone. OWA users will experience the effects of the IE Enhanced Security Configuration when using OWA from a Windows 2003 platform because access to the OWA site will be blocked. When these users attempt to access OWA, IE will display a warning dialog box that informs them about the blocked Web site. To access the OWA Web site, users must add it to the IE Trusted Sites Security Zone, which they can do by clicking Add in the warning dialog box.

When you perform a clean installation of Windows 2003, the installation disables a lot of the services that were enabled by default in Win2K. These services include the Alerter and Telnet services, both of which are popular with Windows and Exchange administrators.

Secure by Default in Exchange 2003
Exchange 2003 includes many traces of Microsoft's secure-by-default effort. For example, in Exchange 2003, only members of the Domain Administrators, Enterprise Administrators, and Exchange Domain Servers groups can create top-level public folders. In Exchange 2000, this permission was given to the Everyone group. In addition, Exchange 2000 contained a bug in the installation procedure that reset the permission to create top-level public folders back to the Everyone group when you installed a new server, even if you'd previously locked down the organization. Exchange 2003 also doesn't grant domain users permission to log on locally to the Exchange server.

Exchange 2003 includes new default message size limits for mailbox and public folder Stores. For an Exchange organization's mailbox Stores, the default message limit (for both sending and receiving messages) is 10MB. The same size limit applies to messages that are posted to a public folder Store. To set the default message limit size for mailbox Stores, you must open Exchange System Manager (ESM), select Message Delivery properties, then select the Defaults tab. To set the default message limit size for public folder Stores, you must open ESM, select the public folder Store's properties, then select the Limits tab.

After you perform a clean installation of Exchange 2003, the installation disables the POP3, IMAP4, and Network News Transfer Protocol (NNTP) services. On all Exchange 2003 installations (i.e., clean installations and upgrades), the installation disables Outlook Mobile Access (OMA), a new Exchange service that enables mail access from mobile devices.

Value-Added Security in IIS 6.0
Like its predecessor, Exchange 2003 requires IIS. This requirement is needed not only for OWA support but also because the Exchange message routing and access engines rely heavily on the IIS transport protocols: SMTP, NNTP, POP3, and HTTP. When you install Windows 2003, IIS is an optional service that isn't installed by default. When you install IIS on a server that you plan to use for Exchange, remember to add SMTP, NNTP, and ASP.NET support. You can add this support by using the Control Panel Add or Remove Programs applet: Select the Windows Component option, open the Application Server section, select the ASP.NET check box, then open the Internet Information Services (IIS) section and select the NNTP service and SMTP service check boxes.

As with Windows 2003, IIS 6.0 installs in a locked-down state. One of the most visible effects of this lockdown is that by default, IIS can provide only static Web page support. Before you can install Exchange 2003, you must configure the IIS installation to serve dynamic Web pages such as Active Server Pages (ASP). You use a new administration feature called Web Service Extensions in the Microsoft Management Console (MMC) IIS Manager snap-in to control which dynamic content IIS can serve. Running Exchange 2003 requires IIS ASP and ASP.NET support. Also, note that the Exchange 2003 installation program adds a set of Exchange-specific extensions, which primarily consist of DLLs that OWA uses.

Perhaps the most fundamental change that makes IIS 6.0 more secure by default is its new architecture. Microsoft has completely reengineered the HTTP portion of the Web server. The key characteristic of this architecture is isolation. IIS 6.0 supports the Worker Process Isolation Mode (WPIM) operation mode, which enables different Web sites (and their worker processes) that are running on the same physical server to operate completely independently of one another—much as if a logical firewall has been set up between them. This mode lets you configure per­Web site security parameters, such as the security identity that a Web site uses, and performance parameters, such as the amount of system resources that a Web site can consume. Also, the architecture provides better protection against Denial of Service (DoS) attacks, which helps ensure that an attack on one Web site doesn't bring down the complete Web server and all the other Web sites running on that server.

Spam Protection
During the past few years, spam (also referred to as unsolicited bulk email—UBE—or unsolicited commercial email—UCE) has become an Exchange administrator's number-one security worry. For an overview of spam-related dangers, read the Internet Mail Consortium report "Unsolicited Bulk Email: Definitions and Problems" (http://www.imc.org/ube-def.html). To combat spam, Exchange 2003 includes better antirelay protection, IP-based connection filtering with support for real-time block lists, SMTP-based sender and recipient filtering, and authenticated Distribution Groups (DGs). Of these features, SMTP-based sender filtering is the only one that was available in Exchange 2000.

Antirelay protection. Spammers often like to use other people's messaging infrastructure to relay their spam messages because it gives them additional processing power and disguises the true originator of a spam message. The Exchange 2003 SMTP messaging gateway turns off message relaying by default so that the Exchange server accepts only messages sent from authenticated sources and messages sent to a recipient whose mailbox is on the server. You can easily test whether message relaying is enabled or disabled by using the Telnet commands that Figure 1 shows. If you send a message to a nonlocal recipient (in the example, [email protected]) and message relaying is disabled, you'll get a 550 SMTP error code. In Exchange 2003, you can set relay restrictions from an SMTP virtual server's properties in ESM (on the Access tab, click Relay Restrictions). By default, an Exchange 2003 SMTP virtual server sets the relay restrictions to Only the list below with an empty computer list, which effectively disables SMTP message relaying. (In Exchange 2000 and Exchange Server 5.5, these servers are open to relay by default.)

Another important new antirelay-related feature is the ability to define user-based relay restrictions. Microsoft also refers to this feature as security principal-based submit and relay. In Exchange 2000, message relaying occurs according to IP address, subnet, or DNS domain name. However, an Exchange 2003 SMTP virtual server includes a new ACL that can define relay restrictions for individual users or groups. To configure this ACL, open the Relay Restrictions dialog box as I described in the previous paragraph, then clear the Allow all computers which successfully authenticate to relay, regardless of the list above check box to enable the Users button. Next, click Users to open an ACL editor that lets you specify which users can submit and relay messages through the virtual server. This new ACL is contained in an SMTP server Active Directory (AD) object's ms-Exch-SubmitRelaySD attribute.

IP-based connection filtering. Exchange 2003's IP-based connection-filtering feature lets you block individual IP addresses or entire lists of IP addresses, such as those that spammers have used as an open proxy to deliver spam. To configure IP-based connection filtering, open the Message Delivery Properties dialog box, which is available through ESM, and select the Connection Filtering tab. Figure 2 shows how to configure IP-based connection filtering for a specific block-list provider, the Mail Abuse Prevention System (MAPS). To create a filter, click Add on the Connection Filtering tab in the Message Delivery Properties dialog box to open the Connection Filtering Rule dialog box, then add the filter name and DNS suffix, as well as any custom error message that you want to appear when this filter blocks a message. Also, on the Connection Filtering tab in the Message Delivery Properties dialog box, you can click Exception to define exceptions to block list—based connection filtering. In addition, you can click Accept or Deny to define global IP-based Accept and Deny lists that bypass the block list—based processing.

Block-list support. Block lists are lists of IP addresses and domains that are known to generate and send spam messages. Specialized online service providers such as MAPS and Spamhaus maintain and distribute these lists. As I described in the previous paragraph, Exchange 2003 supports block lists through IP-based connection filtering. When you enable this feature, every time a remote SMTP server connects to your Exchange server, the server will forward the remote server's address to the block-list provider. The block-list provider will then query its lists. If the provider detects a matching entry, it will return a particular result code to the Exchange server. The server can then act on this result code (e.g., drop the connection to the remote SMTP server).

SMTP-based sender and recipient filtering. A sender filter is a list of email addresses from which you never want to receive mail. You define this list on the Sender Filtering tab of the Message Delivery Properties dialog box, which is available through ESM. In addition, selecting the Filter messages with blank sender check box lets you filter out messages with blank sender information, which is a common spammer technique.

A new spam-protection feature in Exchange 2003 is recipient-based filtering. This feature lets you block incoming messages by dropping the SMTP connection if an SMTP message's MAIL FROM: or RCTP TO: fields contain particular predefined email address strings. You configure recipient-based filtering on the Recipient Filtering tab in the Message Delivery Properties dialog box.

After you define IP-based connection filtering and sender or recipient filters, don't forget to apply them to the SMTP virtual servers that are hosting Internet connectors and that will use the filters. To do so, open the SMTP virtual server's Properties dialog box in ESM. On the General tab, click Advanced. Next, click Edit for the appropriate IP address to open the Identification dialog box, then select the appropriate check box for connection, sender, or recipient filtering.

Authenticated DGs. Authenticated DGs, also known as restricted DGs, are a new property of a Windows DG. Authenticated DGs let only authenticated Windows users send messages to a DG. At the same time, this feature prohibits spammers from misusing a DG to send spam to a DG's members. The new feature is based on the new MS-Exch-Authenticated-Only attribute that's added to a DG's AD attributes. To use this new feature, select the From authenticated users only check box on the Exchange General tab in the DG's Properties dialog box, as Figure 3 shows, which you can access through the MMC Active Directory Users and Computers snap-in.

OWA Security Features
Although OWA has become a popular solution for accessing Exchange mailboxes, many enterprises don't use it because it lacks the appropriate security settings. As a result, Microsoft has included some important new OWA security features in Exchange 2003, including support for Secure MIME (S/MIME)­based mail encryption and signing, junk email filtering, Web beacon suppression, enhanced attachment blocking, and forms- or cookie-based authentication.

S/MIME support. S/MIME is an Internet standard for adding digital signature and encryption support to MIME-formatted messages. S/MIME has been available for a long time for all Microsoft mail clients except OWA. Exchange 2003 now adds this capability to OWA. To use S/MIME in OWA, you must run IE 6.0 or later because IE 6.0 includes client-side logic needed for S/MIME operation in OWA. You enable OWA support in the configuration options of your OWA client. When you enable S/MIME, the OWA server downloads some S/MIME-specific DLLs to your client. If you access OWA from different machines, you'll have to enable S/MIME and download the DLLs on every machine.

To provide your OWA users with S/MIME certificates, you can use an enterprise Public Key Infrastructure (PKI) or third-party certificates. After you enable your OWA client to use S/MIME, the OWA interface and message properties will display options for digitally signing messages and encrypting the message content, as Figure 4 shows. A nice feature of the OWA S/MIME support is that all certificate-related processing, such as revocation checking, is done on the Exchange 2003 server side.

Junk email filtering. OWA now supports junk email filters to help you address all the spam and junk email in your Inbox. This functionality is similar to Outlook 2003's junk email filtering. You can, for example, classify SMTP addresses as safe senders, safe recipients, or blocked senders. When you enable junk email filtering in OWA, the OWA server processes all incoming messages and automatically moves any mail carrying an address that's classified as a blocked sender to the Junk E-mail folder of the user's mailbox. You enable junk email filtering for OWA by using OWA's configuration options—simply select the Filter Junk E-mail check box in the Privacy and Junk E-mail Prevention dialog box, as Figure 5 shows. You can also configure safe senders, safe recipients, and blocked senders by clicking Manage Junk E-mail Lists in the same dialog box. Because OWA and Outlook 2003 share the trusted/junk list, you now get consistent filtering, no matter where users read their mail.

Web beacon suppression. Web beacons are links inserted into HTML mail messages. They can point to images that automatically load when the email client interprets the HTML message, or they can point to URLs that the message invites users to navigate to. Intruders often exploit Web beacons to separate real email addresses from guessed email addresses. When a user opens an HTML-formatted message and the email client attempts to download the image or access the URL, the spammer gets an acknowledgment that the email address is alive. By default, OWA for Exchange 2003 and Outlook 2003 suppress the display of Web beacon content. In doing so, OWA displays a warning message in the header of the mail message that reads To protect your privacy, Outlook Web Access blocked some images or other external content in this message. Click here to unblock content. To control this behavior, you select the Block external content in HTML e-mail messages check box, which is a client-side OWA configuration option, as Figure 5 shows. You can further configure Web beacon suppression in OWA by using server-side registry settings in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchange-WEBOWA registry subkey.

Enhanced attachment blocking. Many intruders use mail attachments to distribute malicious mobile code, such as the Melissa and VBS.LoveLetter viruses, across the Internet and into your mailbox. To block unsafe mail attachments, including .exe files and Windows script files (e.g., .vbs files), Microsoft introduced a mail client feature known as attachment blocking, which blocks attachments according to their file type and MIME type. Outlook 2003, Outlook 2002, Outlook Security Update for Outlook 2000 and Outlook 98 Service Pack 2 (SP2), and Outlook Express 6.0 and later support attachment blocking. Microsoft also introduced a limited version of attachment blocking for OWA in Exchange 2000 SP2. In Exchange 2003, Microsoft introduces attachment blocking for OWA. The OWA server categorizes attachments in three categories (levels 1, 2, and 3)—the category that the mail attachment belongs to determines how the mail client will handle that attachment. To configure OWA attachment blocking, you use several server-side registry settings in the OWA registry subkey I mentioned above.

Forms- or cookie-based authentication. Forms- or cookie-based authentication is a new OWA authentication option that lets you use OWA in kiosk environments. Every time a user logs on to the OWA infrastructure, the OWA front end generates a session cookie that's cached on the browser for the entire OWA logon session. This cookie ensures that users don't need to enter their credentials every time they access another OWA page. Forms authentication also offers secure logoff. As a result, cookies are deleted from the browser cache when the user performs an OWA logoff and users are automatically logged off after a configurable period of OWA inactivity. Before Exchange 2003, OWA architects had to look at third-party software such as Messageware's SecureLogoff to provide these functions. To enable forms-based authentication, you open the ESM and select the Enable Forms Based Authentication check box on the Settings tab of the Exchange Virtual Server Properties dialog box. Microsoft suggests that administrators upgrade all front-end and back-end servers to Exchange 2003 before you use this feature.

Communications Security
Exchange 2003 provides two interesting new communications security enhancements: support for remote procedure call (RPC) over HTTP and support for Kerberos authentication for Messaging API (MAPI) mail clients. RPC over HTTP lets a full-blown Outlook mail client use HTTP to connect to the back-end Exchange infrastructure. RPC over HTTP basically enables the transport of RPC messages by using HTTP. RPC over HTTP offers important advantages from a perimeter security point of view. Instead of opening several RPC ports on the firewall level or instead of guiding a tunnel protocol such as Layer Two Tunneling Protocol (L2TP) through your firewalls, you can now just open the HTTP port to enable Outlook clients to get to their mail. To use RPC over HTTP on the client side, you must run XP SP1 and Outlook 2003 on the client and you must have installed the software patch described in the Microsoft article "Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP" (http://support.microsoft.com/?kbid=331320). Adding this software patch will let you configure RPC over HTTP from the Connection tab of your Outlook 2003 Exchange account by clicking Exchange Proxy Settings to open a dialog box where you can add the protocol and identification verification method that you want to use, as Figure 6 shows. To use RPC over HTTP on the server side, you must run Exchange 2003 and Windows 2003 with IIS 6.0 running in WPIM mode. On Windows 2003, RPC over HTTP relies on the new RPC proxy service. RPC over HTTP is rather complex to set up on the client side. However, it offers you the security advantage of not having to create VPN security holes in your corporate firewalls.

In Exchange 2003, Microsoft also added support for Kerberos-based authentication for MAPI clients. Kerberos, which Internet Engineering Task Force (IETF) Request for Comments (RFC) 1510 defines, is a proven open standard for strong authentication in a distributed client-server environment. To take advantage of Kerberos-based authentication for MAPI, you must be running Outlook 2003 on the client side. You configure Kerberos by accessing the Security tab of your Outlook 2003 Exchange account and selecting the Kerberos Password Authentication option from the Logon network security drop-down menu, as appropriate, as Figure 7 shows.

Other Security Enhancements
Exchange 2003 includes several mission-critical security enhancements, many
of which I've discussed in this article. Starting with its secure-by-default initiative, Microsoft has taken steps to lock down Exchange 2003 and related components right out of the box. Exchange 2003 offers vast improvements in spam protection by letting you filter IP addresses, configure block lists, establish sender and recipient filters, and authenticate DGs. Exchange 2003 also offers better integration with security features in OWA for Exchange 2003, including S/MIME support, junk email filtering, Web beacon suppression, attachment blocking, and new authentication options.

Another less-apparent security-related change is the inclusion of the new Virus Scanning API (VS API) 2.5. One key feature of VS API 2.5 is the enhanced support for antivirus notification and status messages. Another important but often overlooked security change is the enhanced IP Security (IPSec) support for front-end and back-end communication security. Perhaps the most important message to remember is that most of Exchange 2003's security changes require an underlying Windows 2003 and IIS 6.0 infrastructure on the server side and Outlook 2003 and IE 6.0 on the client side.