9.6 Locking down and securing your Exchange servers | Mission-Critical Microsoft Exchange 2003: Designing and Building Reliable Exchange Servers (HP Technologies)

9.6.1 General Exchange security considerations

When considering how to increase the security of Exchange, it is important to remember that Exchange is actually a number of processes that communicate with each other on local and remote computers. Specifically, Exchange servers need to communicate with other Exchange servers and DCs and a number of different clients. IIS is integral to the functionality of Exchange and Exchange servers can even be accessed through the file system. This series of complicated relationships means that when attempting to lock down Exchange servers, you should consider the following components:

Service security
File system security
IIS security
Registry security
AD security
Exchange database security
Exchange transport mechanisms
Exchange service dependencies

One key area to look at is Exchange services. Exchange runs on Windows Server and requires that some Windows services be running either to install the product or for it to continue to function properly. Some Exchange services are also dependent on other Exchange services. Figure 9.3 shows the services that run on an Exchange server by default and the dependencies they have on each other. You also need to take into account the trade-off of enhanced security measures versus reduced features and increased complexity.

click to expand
Figure 9.3: Windows and Exchange services dependencies.

Exchange Server patch management

To keep Exchange as secure as possible over time, you will need to make sure you remain current on the latest patches. There are two elements to this— making sure the operating system is up to date and making sure that Exchange is up to date. If the operating system is vulnerable, then Exchange is also vulnerable, so you should treat the security of the operating system very seriously on Exchange servers. There are a number of utilities available that will keep you current on Windows service packs, hot fixes, and patches. Microsoft supplies the MSBSA (discussed earlier) to help you with this.

Protecting against mail address spoofing

One of the most common ways of attacking an e-mail system is by manipulating the From: field in an e-mail message. SMTP does not check to verify a user’s identity, but you can perform some actions in Exchange to try to minimize message spoofing. One of the most insidious problems with address spoofing is external attackers forging e-mail with the e-mail address of an internal user. This can be used in a number of ways, often as a form of social engineering, to persuade another user to give up confidential information, which in turn leads to further attack. By default, Exchange 2000/ 2003 will resolve an e-mail address in its address book to the name used in the global address list. This can make it very difficult to tell if a message has actually originated outside the organization because, to the recipient, the mail appears to have the same address and account information as a legitimate message would have. You can change the default behavior, so that SMTP addresses on mail from outside the organization always remain unresolved. If you then educate users to look for unresolved e-mail addresses, it will help you guard against this form of address spoofing.

If you are receiving messages directly from other domains on the Internet, you can configure your SMTP virtual server to perform a reverse DNS lookup on incoming e-mail messages. This verifies that the senders, mail IP address (and fully qualified domain name) corresponds to the domain name listed in the message. Reverse lookup does place an additional load on the Exchange server. It also requires that the Exchange server be able to contact the reverse lookup zones for the sending domain; for messages sent from internal servers on foreign networks, the name resolution may not always work.

9.6.2 Security enhancements in Exchange Server 2003

For Exchange 2003, the development team at Microsoft took a look at the specific deficiencies they discovered after an extensive security audit of the Exchange code as well as deployment data. The mindset they came up with was to focus on these deficiencies for Exchange 2003 and substantially improve the security posture of the product. At the same time, Microsoft as a company has undergone a dramatic shift in focus on security that has benefited the Exchange product as well. The product group focused their efforts on leveraging some key areas in Windows to improve overall Exchange security—Kerberos, Windows ACLs, and Windows PKI.

Kerberos authentication

Exchange 2003 and Outlook 2003 can now use Kerberos to authenticate users to the Exchange servers. If your network uses Microsoft Windows 2003 Server DCs, your users can authenticate cross-forest to the DCs in trusted forests allowing user accounts as well as Exchange servers to exist in different forests. Exchange 2003 also uses Kerberos delegation when sending user credentials between an Exchange front-end server and the Exchange back-end servers. Previous versions of Exchange Server used basic authentication to send credentials between an Exchange front-end server and an Exchange back-end server when users used OWA. As a result, companies needed to use a security mechanism such as IPSec or SSL to encrypt information from the Exchange front-end server to the Exchange back-end servers.

SMTP transport connection and recipient filtering

Exchange 2003 adds connection filtering and real-time block listing (also called DNS block listing) features, allowing administrators to deny SMTP connectivity based on IP addresses or the popular Real-Time Block List (RBL) services available on the Internet. Connection filtering leverages externally based services that list known sources of unsolicited e-mail; dial-up user account lists and servers open for relay based on IP addresses. Connection filtering complements third-party content-filter products. This feature allows you to check an incoming IP address against an RBL providers list for the categories you want to filter. If a match is found on the RBL provider’s list, SMTP issues a “550 5. x.x” error in response to the RCPT TO: command. Recipient filtering is defined as the ability to block incoming mail by dropping the connection if the “ Mail From:” or “RCPT TO:” protocol commands contain a string that matches an administratively specified addresses. Exchange 2003 implements recipient validation based on per-recipient validation and lists of known recipients to be blocked (using RCPT TO:).

Exchange virus scanning API version 2.5

The updated Virus Scanning API (VSAPI) now runs on SMTP and bridgehead servers (not just Exchange stores) by adding a Transport event sink hands off to store-based antivirus scanner. The new VSAPI also allows antivirus vendors to mark and/or delete infected mail and send a message to the recipient indicating that the message was contaminated. In addition, the API also provides better virus status messages to clients. Combined with the antivirus and attachment-blocking measures in Outlook 2003, end-to-end messaging system security has been greatly enhanced in this area.

Outlook Web Access security enhancements

A number of improvements have been made to the security of the OWA feature of Exchange. The following list covers the key highlights.

OWA forms-based logon/cookie authentication: You can enable a new logon page for OWA that will store the user’s user name and password in a cookie instead of in the browser. When a user closes his or her browser, the cookie will be cleared. Additionally, after a period of inactivity, the cookie will be cleared automatically. The new logon page requires users to enter either his or her domain name/alias and password or his or her full UPN e-mail address and password to access his or her e-mail.
OWA junk mail beacon blocking: OWA makes it tougher for people who send junk mail to use beacons to retrieve e-mail addresses. Beacons are Trojan code that informs the sender that the e-mail address is valid and useful for future junk mail campaigns. Now an incoming message with any content that could be used as a beacon, regardless of whether the message actually contains a beacon, prompts OWA to display a warning message.
OWA attachment blocking: There are a host of new attachment-blocking features in OWA that you can enable. Administrators can block OWA users who log on through the Internet from accessing any attachments in messages. This is particularly useful for keeping users from potentially compromising corporate security by opening attachments when using OWA at public Internet kiosks. At the same time, administrators can allow full intranet access to attachments in messages, so users working with OWA in their offices or connected to the corporate network from home could open and read attachments. A warning message in the OWA infobar of the e-mail where attachments have been blocked will let users know if they are not able to access attachments. Administrators also can block OWA users from sending or receiving attachments with specific file extensions that could contain viruses. This new OWA feature matches attachment-blocking functionality in Outlook. On received messages, users will be told via the OWA infobar of any blocked attachments. On sent messages, OWA will not allow users to upload any files with extensions that appear on the block list.
OWA S/MIME support: The Secure Multipurpose Internet Mail Extensions (S/MIME) protocol allows users to send secure e-mail by digitally signing or encrypting e-mail messages. Signed and encrypted e-mail was not supported in OWA with Exchange 2000. In Outlook Web Access with Exchange 2003, users can digitally sign and encrypt e-mail messages using the new OWA S/MIME control. The S/MIME control works in conjunction with a public key infrastructure (PKI) to provide signing and encryption capabilities. Users still need to have their private keys and certificates on their local computers ( usually in the form of either a smart card or a PFX file); the OWA S/MIME ActiveX control can use these keys locally to avoid disclosing them to the server.

Mobility security enhancements

Pocket PC, Pocket PC Phone Edition, and Windows Powered SmartPhones can securely (SSL 128 bit) synch with Exchange 2003 directly through the new Outlook Mobile Access (OMA) component. OMA is very similar to OWA in many respects, but OMA is optimized for mobile devices and their small screens and more limited user interfaces. OMA also supports mobile browsing via its improved support for key browsing technologies such as HTML, cHTML (Japanese market), and xHTML (WAP 2.0). As part of the secure-by-default strategy, OMA is turned off by default.

RPC over HTTP (also called Outlook over the Internet) is another impressive new mobility feature of Exchange 2003 and Outlook 2003. RPC over HTTP provides Outlook 2003 users the ability to make MAPI RPC connections via secure HTTPS connections (RPC is tunneled inside HTTPS using the SOAP protocol). This allows Outlook 2003 users to synchronize and access Outlook information through firewalls. Obviously, this is a feature that requires a fair amount of security planning and design. If you choose to deploy this feature, ensure that you understand how it works and how to secure it.

9.6.3 Leveraging policies for Exchange servers

It is possible to define a large number of security settings in Windows, including auditing, security options, registry settings, file permissions, and services. Before you focus on Exchange Server role-based policies, ensure that you have addressed the Windows Server role-based policies for your Exchange servers. The main area where additional role-based policy settings are applied with Exchange servers is for services. As they reside in OUs below the Member Servers OU, the Exchange servers inherit settings defined in the Member Server Baseline Policy (a default Windows Server policy that should be applied to Exchange servers). It is a good idea to place Exchange servers in their own OUs to facilitate management, administration, and security granularity and flexibility. The Exchange policies modify those settings in two ways. First, some services that are not required for basic Windows functionality are needed for successful Exchange operations. Second, Exchange 2000/2003 introduces a number of extra services, not all of which are required to allow the Exchange servers to function in their particular roles. In the Exchange Security Operations Guide, Microsoft provides policy templates for two key server roles: back-end server and OWA front-end server. You will need to import these templates into your Windows Group Policy settings in order to use them with Exchange.

Back-end server policy

The Exchange Server Back-end Policy defines settings in two areas: services and file ACLs.

Table 9.5: Exchange Back-End Server Policy Service Configuration
Service	Startup State	Justification
Microsoft Exchange IMAP4	Disabled	Server not configured for IMAP4
Microsoft Exchange Information Store	Automatic	Needed to access Exchange stores
Microsoft Exchange POP3	Disabled	Server not configured for POP3
Microsoft Search	Disabled	Not required
Microsoft Exchange Site Replication Service	Disabled	Not required (legacy support only)
Windows WMI	Automatic	Required for Exchange Management
Microsoft Exchange MTA	Disabled	Not required (legacy support only)
Microsoft Exchange System Attendant	Automatic	Required for other services
Microsoft Exchange Routing	Automatic	Required for routing
Microsoft Exchange Management	Automatic	Required for management tools
IPSec Policy Agent	Automatic	Required for IPSec on server
RPC Locator	Automatic	Required for communication
IIS Admin Service	Automatic	Required by Exchange Routing
NTLM Security Support Provider	Automatic	Required by Exchange System Attendant
Microsoft Exchange SMTP	Automatic	Required by Exchange
WWW Publishing Service	Automatic	Required for OWA and front-end server communication

OWA server policy

The OWA Front-end Policy defines settings in two areas—services and file ACLs. Since the role of this server is to only support Web-based e-mail, many of the Exchange services installed by the default configuration can be disabled. Table 9.6 shows the services that are configured in the OWA Front-End Server Policy. In the event that a front-end server also hosts IMAP, SMTP, and POP, you will have to determine which of the policy attributes are applicable.

Table 9.6: Exchange OWA Server Policy Attributes
Service	Startup State	Justification
Microsoft Exchange IMAP4	Disabled	Server not configured for IMAP4
Microsoft Exchange Information Store	Disabled	Not required as there is no mailbox store or public folder store
Microsoft Exchange POP3	Disabled	Server not configured for POP3
Microsoft Search	Disabled	Not required—no stores
Microsoft Exchange Site Replication Service	Disabled	Not required (legacy support only)
Microsoft Exchange MTA	Disabled	Not required (legacy support only)
Microsoft Exchange System Attendant	Disabled	Only required if you wish to make configuration changes to the server.
Microsoft Exchange Routing	Automatic	Required for routing
Microsoft Exchange Management	Disabled	Not required for OWA
IPSec Policy Agent	Automatic	Required for IPSec on OWA server
RPC Locator	Automatic	Required for communication
IIS Admin Service	Automatic	Required by Exchange Routing
NTLM Security Support Provider	Automatic	Required by Exchange System Attendant
Microsoft Exchange SMTP	Automatic	Required by Exchange
WWW Publishing Service	Automatic	Required for OWA and front-end server communication

9.6.4 IIS lockdown tool and Exchange

After you apply the respective security template to your Exchange 2000/ 2003 servers, you will need to apply additional security controls on IIS, particularly on your OWA front-end servers. To automate many of the changes to IIS, the IIS Lockdown tool can be used. IIS Lockdown will specify settings needed to harden IIS, but still allow Exchange 2000/2003 to function as either a back-end server or an OWA front-end server. The IIS Lockdown tool has two modes: an express mode appropriate for most basic Web servers and an advanced mode that allows administrators to pick and choose the technologies that the server will support. The tool provides an undo feature that allows the effects of the most recent lockdown to be reversed. IIS Lockdown also implements URLScan, which screens all incoming requests to an IIS server and only allows those that comply with a specific rule set to pass. This significantly improves the security of the server by helping to ensure that it responds only to valid requests. URLScan allows you to filter requests based on length, character set, content and other factors. A default rule set is provided, which can be customized to meet the needs of a particular server. For more information on the IIS Lockdown tool, please see www.microsoft.com/technet/security/tools/ tools/locktool.asp.

9.6.5 Exchange server network security

Typically, we think of network security as protecting us from network intrusions and threats from outside sources. We look to measures such as firewalls, proxy servers, virtual private networks (VPNs), and network design as protection mechanisms against these threats. Starting with Exchange 5.0 in 1997, close integration with the Internet was provided. Further enhanced in Exchange 5.5, our awareness of the vulnerabilities of such great integration only surfaced in the last few years. It has only been in recent years that Exchange servers have been used as Internet gateways, handling inbound and outbound mail traffic for many organizations. With Exchange 2000/2003, integration with the Internet and standard protocols such as SMTP, IMAP4, POP3, NNTP, and HTTP has grown to a level that makes it an attractive platform for companies using Exchange as a gateway to the Internet, as well as for ISP/ASP using Exchange as a hosting platform for millions of users. This increased integration and versatility should serve as a warning of the increased need to protect Exchange Server from unauthorized access, DoS, and other attacks. This section will look at the ways we should protect Exchange servers functioning as gateways to the Internet.

We will overview methods available to protect Exchange and your network, including monitoring and detection, firewalls and proxy servers, and securing Exchange SMTP virtual servers.

Monitoring and detection

Since Exchange servers that are accessed externally via the Internet may support a wide variety of protocols, it is too simple a philosophy that only worries about SMTP. While SMTP access is the most common example, enhancements to Exchange 2000/2003 OWA and the use of Exchange as a hosting platform for ISPs will bring other protocols like HTTP to the forefront. While we need to focus on locking down the points of access and limiting the protocols available (which we will cover later), we need to ensure that methods are available to track and monitor the access to and use of the services that are exposed and vulnerable. Hopefully, your organization already has many of these tools and procedures in place, and you can simply ensure that they consider your Exchange deployment’s needs. If not, we should look at some of the basics that you will want to consider to provide adequate monitoring and detection measures.

Detecting security incidents and attacks is not necessarily the rocket science it is sometimes made out to be. In fact, there are many tools built into Windows that can get you started. Many times, the most useful tool can be the Windows system security log. This often-overlooked component of the system event logging process can be an invaluable tool for providing data about suspect security events. Table 9.7 lists some situations and scenarios that may be deemed suspect and may indicate a security breach.

Table 9.7: Common Indicators of a Security Breach
Unusual time of usage	Attackers often strike during off hours when there is a lower chance they will be detected or countermeasures will be applied. Security events logged during off business hours may need to be more closely scrutinized.
Unusual usage patterns	If a novice or non-administrative user is performing functions or generating error codes that are atypical for this user, the account may have been compromised.
Irregular account usage	Windows 2000 comes with several default accounts such as Guest and Administrator. However, many installations change or add other default accounts used for privileged accesses. New and unfamiliar accounts on the system may also be suspect. In addition, activity in a previously inactive account could also be cause for concern.
Unexplained changes to permissions or files	Once an attacker gains access to your system, traces of the activity may need to be covered or new backdoors added.
Gaps in system and security logs	System logs typically show patterns of activity for all hours. Missing time segments or drastic changes in activity recorded in logs may be a cause for concern.

For Exchange 2000/2003 and Windows, the system logs can be a valuable source of detection and monitoring information. However, this is most useful when other sources of information are available to correlate events recorded in logs. Protocol Logging is another valuable tool. Exchange 2000/ 2003 relies on IIS to support Internet protocols such as SMTP, IMAP, POP3, NNTP, and HTTP. For SMTP, NNTP, and HTTP, IIS comes with a utility for logging the commands made on IIS virtual servers hosting these protocols. These protocol logs track commands that the virtual servers receive from connections made from clients and other servers. When connecting to these virtual servers, clients and servers engage in a dialog of commands that, under normal circumstances, facilitate the flow of data over these protocols. For example, in earlier versions of SMTP (not Exchange), it was possible for an attacker to Telnet to an SMTP server, enter a string of characters, and terminate the connection, causing the SMTP service to fail. Protocol logging would provide some evidence in this type of attack that would be useful in tracking down the attacker. In conjunction with system event logs, protocol logging on services that are potentially exposed will provide strong evidence that will be useful for tracking attacks when they occur and preventing future attacks from occurring. In addition, you can use protocol logging to provide auditing for users and commands throughout your environment as an additional precautionary and preventative measure.

Once you have investigated and deployed basic measures, such as security event and protocol logging, you may want to go one step further and deploy full-blown intrusion-detection measures. More and more intrusion-detection tools are becoming available as many companies scramble to fill this market need. In the book Internet Security for Business, intrusion-detection tools are divided into four categories (maybe somewhat oversimplified, but helpful), as shown in Table 9.8.

Table 9.8: Categories of Intrusion-Detection Tools
Statistical tools	These tools are based on normal behaviors and access patterns for users and administrators. These patterns are measured by these tools over time and provide statistical norms upon which to based extraordinary evaluations. Deviation from the norms often indicates that intrusions have occurred.
Signature-based tools	Some user and administrative commands (the signature) are indicators of security breaches or unauthorized activities. These attack signatures are used to trigger alerts on security incidents.
State–transition-based tools	These tools are based on the assumption that unauthorized changes in account states (i.e., to Administrator or Domain Admin privileges) are based on predicable patterns and can be used to indicate breaches in certain types of services.
Expert system tools	Many of the leading intrusion-detection tools have these “expert” capabilities that use rules to evaluate system-access data and patterns in the same way security experts do manually. These tools represent security-intrusion-detection expertise packaged into a product.

Obviously, many tools combine these categories into one tool. There are many tools available today that provide network mapping, port scanning, and intrusion detection all rolled into one. If your organization has not looked at these tools and assessed what capabilities are needed to protect your Exchange environment, I recommend that you spend some time on this topic in order to protect your deployment. Monitoring and detection are important measures required for services such as Exchange SMTP virtual servers or OWA servers that are vulnerable and exposed to the Internet. In the next section, I will look at firewall technology and provide some suggestions as to how this technology can complement your monitoring and intrusion-detection measures.

Firewall technology

Typically, when we think of network protection and access control, we think of firewall technology. As the name implies, a firewall is designed to protect or minimize potential damage from security incidents and attacks. Firewall technology represents the best technology available to protect Exchange and other systems from attack from outside sources. For Exchange servers deployed throughout your intranet, firewall technology is not targeted at protecting these systems. The focus of this section will be on how firewall technology can help protect Exchange servers that are located at the perimeter of your network and are exposed or partially exposed to attack.

We should start by covering some firewall basics. While I do not intend to give you an in-depth tutorial on firewall technologies, I do want to lay a bit of groundwork for later discussions and application to Exchange. Firewall products available today provide a range of functions and features. These features can range from the simple packet filter to complex systems that provide detailed analysis and management at the application layer. Application layer proxies act as a protective relay for Exchange SMTP mail and other services between internal mail systems and hosts on the Internet. In addition, a firewall does not necessarily consist of a single computer, but can be a collection of systems that together provide the functionality required to protect your internal network and services. There are several types of systems that fall into the category of firewall technology. Table 9.9 highlights several of the most common firewall protection mechanisms available.

Table 9.9: Basic Firewall Technologies
Technology	Limitations	Description
Packet filter	No application support No authentication Does not hide internal network	Typically implemented at the router, packet filtering scans incoming packet traffic for configured protocols and compares the traffic to a defined rule set of filters. A decision is then made whether to allow, drop, or reject the incoming packet.
Application proxy	Session overhead Cost Inconvenience	A dual-homed system, proxy servers adopt a store-and-forward design to terminate all connections at the firewall. Proxy servers work at the application level and act on behalf of clients inside the network perimeter and servers outside.
Circuit proxy	Client configuration required Non-application-specific	A variant of a traditional proxy server, the circuit proxy goes beyond the traditional proxy and provides a transparent end-to-end virtual circuit between clients and servers.

Lest you get the impression that firewall technology is the complete answer, it is important to clarify some limitations of firewall technology. First, firewalls do not provide any data protection or integrity. For example, it is not always (usually) the role of a firewall to eliminate viruses in the incoming traffic. This would be too great a performance burden on a typical firewall. Another limitation relates to authentication. Firewalls provide none since they only look at packets and application traffic. Thus, firewalls do not specifically prevent spoofing attacks. If you want data encryption and confidentiality of your data, only IPSec-capable firewalls can provide this ability. The final point is that firewalls do not protect you from internal attacks and are only one entry point into your network. There are several excellent firewall technology vendors on the market, such as Symantec (Axent) Raptor and Checkpoint (noted leaders), as well as Microsoft’s own ISA (Internet Security and Acceleration) Server (which provides specific benefits for Exchange deployments such as SMTP antivirus support, RPC Proxy, and Exchange front-end server support), that apply a combination of the technologies discussed into their products.

Firewall technology is a vital part of protecting your Exchange deployment (especially those Exchange servers exposed to the Internet), but it does not provide the complete solution. Proper authentication, monitoring, and intrusion-detection techniques are also required. By leveraging firewall technology with other measures, you can provide the needed protection for mission-critical Exchange systems.

click to expand
Figure 9.4: Example of firewall architecture Alpha.

Example firewall architectures for Exchange

There are many design methods and techniques for deploying firewall technology with Exchange Server. In this section, I will look at three potential architectures that you may choose to implement (or may have already implemented in your organization). These designs are focused on Exchange-specific services, such as SMTP and HTTP, which are the most typical. However, these designs could be applied to a variety of other applications and protocols.

Architecture Alpha—basic packet filtering/screening router: One approach is to place a filtering or screening router as the first point of presence of your connection to the Internet. This router could be owned and managed by your organization or the ISP that provides your access to the Internet. The router acts as the first line of defense and provides packet filtering according to the rules configured. Only traffic matching the configured policies is allowed access internally. Services such as an Exchange SMTP virtual server or OWA server would be located behind this filtering router. Between the intranet and this host, another secondary router would be located. The screening router will allow internal traffic to flow freely in an outbound direction, but only allow incoming traffic on certain TCP/UDP ports, depending on the services supported. For example, for Exchange SMTP virtual servers acting as an Internet mail gateway for the organization, TCP ports 25 (SMTP) and 465 (SMTP via SSL) would need to be enabled at the screening router. The router would then allow incoming connections from other SMTP servers on the Internet to establish connections and transfer mail to your organization. The downside to this architecture is that the screening router is really the only protection mechanism between the outside network and your internal network. Of course, most organizations deploying such architectures would most likely want to place an additional router between the host running external services such as SMTP or HTTP and the internal network. This creates a buffer zone often called a Demilitarized Zone (DMZ), as shown in the next architecture.

Architecture Bravo—screening router with DMZ: This builds on the previous architecture (Alpha) and adds the concept of a DMZ. The DMZ acts as an intermediate subnet that “insulates” the internal network from the Internet (shown in Figure 9.5). External services such as an organization’s Web or FTP server would reside on the DMZ subnet. In addition, a proxy server host would be located on the DMZ and proxy other more sensitive services on the internal network. The proxy server host would both act as a gateway to the internal network as well as perform proxy functions. Alternatively, Exchange SMTP virtual servers could be located on the DMZ subnet along with other public servers (such as Web servers). The degree of protection is dependent on how complicated you want your design to be. Keep in mind that the more secure your design is, the more management and administration it requires. Additionally, this design could be further extended by adding a further degree of network separation, as shown in Figure 9.6.

Figure 9.5: Example of firewall architecture Bravo.

Figure 9.6: Example of firewall architecture Charlie.
Architecture Charlie—highest security: This configuration continues to build on the previous two and further extends the security barrier by placing the secondary screening router directly between the internal network and the DMZ. The principals are the same as in the two previous architectures: An external router filters packets and protects services exposed to the Internet such as SMTP. Instead of a proxy server acting as both the gateway and the proxy for internal networks, the functions of gateway and proxy are divided by adding an additional screening router as a gateway protecting internal networks and a separate proxy host dedicated to this role. In the book Internet Security for Business, the authors refer to this architecture as the “belt-and-suspenders” architecture. As the name implies, this architecture provides two ways to “keep your pants up.” In the previous architecture (Architecture Bravo), one host provided both functions (proxy and gateway). In architecture Charlie, the additional router and separation of roles add an additional line of defense that, while subtle, can be an important added extra measure.

These example firewall architectures certainly do not represent the only design methods for protecting Exchange and other services exposed to the Internet. However, these architectures are fundamental, and most variants will be closely rooted to one of these approaches. Advances in firewall technologies are coming with each new release of vendor software. In addition, organizations with services exposed to the Internet are more cautious than they used to be. Regardless of which architecture your organization deploys for Windows and Exchange, ensure that the one your organization has in place or is planning to deploy provides adequate protection for Exchange services like SMTP and HTTP. Also, don’t forget to familiarize yourself with the protocols and TCP/UDP ports that Windows and Exchange utilize. Finally, the Microsoft Exchange Security Operations Guide provides extensive design examples and details regarding protecting your Exchange services (such as SMTP, OWA, Outlook Mobile Access, Exchange Active-Sync, and RPC over HTTP) behind firewall configurations.

9.6.6 Tackling viruses

On Friday, March 26, 1999, several corporate networks across the world were stricken with a Microsoft Word macro virus referred to as Melissa. Because of its unusual ability to propagate itself through electronic mail, the virus forced companies to disable portions of their e-mail systems to prevent further propagation both within and outside of their firms. Besides self-propagation, the virus sent inappropriate e-mail to addresses it found in personal address books on Microsoft Outlook mail clients. The virus used well-documented methods that provided a way for unsuspecting users to infect an entire organization. Melissa was a Word macro virus that was attached to an e-mail message. Once a user launched the attachment, the Word macro modified the standard template (NORMAL.DOT) by adding virus macro code. While not data-destructive, the virus code would replicate itself by sending copies of the virus to large blocks of recipients in the Global Address List (GAL). This often resulted in Exchange servers throughout an organization being choked as the amount of mail traffic grew exponentially as the virus replicated itself. While rather simple, the Melissa virus demonstrated clearly how vulnerable our Exchange systems are to DoS attacks. Later attacks such as WormExplore.Zip and the ILOVEYOU virus have only reinforced this point.

More recently, spam or UCE has become the scourge of Exchange administrators—clogging Internet gateway message stores and inboxes. As I discussed above, many companies are seeing a significant portion of inbound e-mail traffic as spam, and antispam solutions are just beginning to mature to effective protection measures. In order for Exchange deployments to operate with maximum availability and meet SLAs, adequate protection measures must be in place against virus and spam attacks. If Exchange administrators ignore this advice, this area will simply become the weakest link in their Exchange deployment’s high-availability chain. In this section, I want to focus on the approaches to preventing virus and spam attacks in an Exchange environment. I will discuss a three-tier approach to virus prevention: the technologies and vendors available and how to select a vendor. Finally, we will look at the deployment points or scenarios for antivirus solutions in your environment.

Perimeters of defense

When you view your organization with respect to viral infection, think of it as a fortress of services with limited access points. These access points are (1) the Internet, (2) the server store, and (3) the client device. For an antivirus or antispam solution in your organization to be complete, it will need to provide protection for these three perimeters of defense.

The first perimeter or tier of protection needs to protect the client device (usually a desktop PC). It is here that floppy disks can be accessed and viruses spread. Macro viruses also originate at the client PC as individuals connect to shared drives and access common files that can be infected with macro viruses as in the case of the Melissa virus. At the client perimeter, you have only one option: file-level antiviral solutions. These products provide real-time in-memory and file-based scanning for both local and attached network drives. Besides real-time scanning, manual scans are also available. Like all antivirus solutions, these products rely on signature files that identify viruses and provide the ability to clean them from a system. The best practice for the client perimeter of defense is to implement scanning products and provide a secure desktop environment that limits current users’ local client permissions to those that are nondestructive (since a virus program would run under the current context of the logged on user). While real-time and file-based scanning programs are a key part of a total antivirus strategy, they are usually not the concern of the Exchange system manager.

More recently, Microsoft has looked closer at the specific vulnerabilities on the client side (Outlook) and has provided specific security enhancements for Outlook that limit the abilities of viruses targeted at Outlook vulnerabilities. In Outlook 2003, Microsoft has made huge improvements on both the antivirus and antispam front. In fact, there has been an increased focus on linking the client and server to help the users control viruses and spam content that get through to their inbox. In addition, improvements in Exchange 2003 allow VSAPI to run on SMTP and bridgehead servers (not just Exchange Stores) by adding a Transport event sink hands off to storebased antivirus scanner. The new VSAPI also allows antivirus vendors to mark and/or delete infected mail and send a message to recipients and is fully backward compatible with earlier implementations of the VSAPI. Combined with the antivirus and attachment-blocking measures in Outlook 2003, end-to-end messaging system security has been greatly enhanced in this area.

The second tier or perimeter of defense for an organization is the servers where files and user data are stored. File servers are important servers for which to implement sound antivirus solutions, but it is the Exchange information store that is the primary concern of Exchange system managers. Most messaging systems like Exchange store data in a proprietary database format such as Exchange’s ESE discussed in Chapter 3. Traditional file-server-based antivirus scanning engines must not scan these stores because those scanners don’t know how to safely scan, much less modify, the ESE and STM file formats. In order to scan Exchange Server information stores, vendors of antivirus solutions must use Microsoft’s APIs to access Exchange stores directly and provide scanning of e-mail attachments directly. This is accomplished in several ways. One method allows the antivirus product to log on to the Exchange server as a privileged user and uses the MAPI protocol to open each individual mailbox and scan messages for attachments (this is now an outdated and unsupported approach, but it is still offered by some antivirus vendors). The attachments that are infected can be cleaned and are typically replaced by a friendly notice indicating that the message contained a virus and was cleaned.

Microsoft provides the last approach as a result of efforts from antivirus vendors who reverse-engineered the access to the Exchange database engine and made supporting Exchange a nightmare. Provided in Exchange 5.5 Service Pack 3, the antivirus API (AVAPI)—now called the VSAPI in Exchange 2003—provides vendors a supported interface in which to access the Exchange information store without having to use MAPI or engage in unsupported methods. This API is carried forward in Exchange 2000 and further enhanced in Exchange Server 2003, and many vendors have support for the API. For a complete and updated listing of vendors supporting Exchange’s VSAPI, see www.microsoft.com/exchange/partners/antivirus.asp.

The final access point (and perimeter of defense) into your environment can also be protected from potential virus infection. This perimeter is the point of entry to your systems from the Internet. We discussed earlier in the chapter how this gateway can be protected via firewall architectures. However, I deferred specific discussions around antivirus protection to this section. At this point of access into an organization, SMTP mail is delivered and routed throughout an Exchange environment. Most organizations have SMTP mail services that provide an access point exposed to the Internet as discussed earlier. SMTP mail traffic then either is routed directly to “home” servers where users reside or routed to an internal SMTP relay host for eventual routing to final destinations.

It is at this entry point into the organization that many virus threats can be stifled. As SMTP-based mail enters into an organization, it can be scanned for viral content. This gateway/firewall-level protection scans attachments entering from the Internet and can remove viruses and other undesirable content before they enter the organization. This eliminates the propagation of such content and provides a method of containment. Most products on the market can capture a high percentage (95% to 99%) of unwanted files and content. A complete protection scheme to prevent virus outbreaks in your Exchange deployment is an approach that combines gateway/firewall scanning with protective measures at the other perimeters of defense (client device and server store). Many of the antivirus vendors provide both capabilities within a single product family. Others have chosen to focus on only one area. The listing is by no means a recommendation or an exhaustive list of all products on the market. However, when selecting antivirus solutions, many of these products will most likely end up on your short list.

The key motivating factor for deploying an antivirus solution lies in the fact that virus creation and infection are on the rise and e-mail will become the primary source of infection. Support staffs will be buried in the administrative burden of virus control and disaster recovery unless an organization selects and deploys a solid antivirus solution. The solution needs to address every perimeter of defense—client, store, and gateway. Unless organizations have these mechanisms of protection in place, virus infestations will continue to cause unwanted and unnecessary downtime for messaging systems. When selecting from the myriad of antivirus solution vendors available, you are faced with a difficult decision as to which product is right for your organization. You can select the product that has the “best” features, use one that you already own, or engage in a complex process of elimination that is based on certain criteria, performance, and functionality. This process and method of selection will vary for each organization according to its needs. Table 9.10 provides some important criteria I recommend for selecting an antivirus solution.

Table 9.10: Criteria for Selecting an Antivirus Solution
Vendor focus	Does the vendor focus on antivirus solutions that are full featured and provide a complete comprehensive solution? Or does it focus on a niche or one perimeter of defense? For example, does the vendor offer only a gateway scanning product or an entire suite that covers all three perimeters? I recommend a comprehensive solution.
Vendor support	Antivirus technology is advancing at a rapid pace. How quickly does a vendor update its products? How soon are new technologies such as the Exchange ESE AVAPI versions leveraged? In addition, how soon are service packs, hot fixes, and new virus signature files made available? Finally, when you need assistance installing or supporting a solution, how responsive is the vendor?
Performance impact	In particular, store-based scanning can be quite resource intensive for an Exchange server. Carefully evaluate and test the impact each vendor has on server system resources. Higher resource utilization does not necessarily equate to more effective scanning.
Multiengine support	One way to ensure effective scanning and to increase the chances of detection is to deploy multiple scanning engines. For example, an organization may deploy one engine at the gateway, another at the store, and still another at the client. Some products allow engines to be interchanged in order to serve this purpose.
Detection rates	Most vendors claim high virus- and content-detection rates for their products. You may want to investigate this further and establish a standardized testing and evaluation procedure for products as part of your selection process.

click to expand
Figure 9.7: On access virus scanning mode.

It is clear that deployment of a good antivirus solution for your organization is of paramount concern for mission-critical systems. If you have not invested in this sometimes-overlooked area of protection, take steps now to select, pilot, and implement a comprehensive antivirus solution organization-wide. Implementing scanning at your gateways, server stores, and clients covers the key perimeters of defense. In addition to implementing a good antivirus strategy, don’t forget the basics, such as good security measures, monitoring and intrusion-detection techniques, and solid disaster recovery-practices and procedures. Also conduct thorough pilot testing before rolling out an antivirus solution in order to minimize risks involved. This vital area can be a key to maintaining a highly available Exchange deployment.

Virus scanning for Exchange 101

From an Exchange perspective there is now only one framework in which to implement virus scanning for Exchange information stores. Prior to the Exchange VSAPI, another method, MAPI Notification, was available and implemented by most antivirus vendors, but was frought with problems and was a support nightmare for Microsoft. With the advent of the VSAPI there is essentially one framework for antivirus in Exchange that yields three core scanning modes of operation.

On access scanning: This mode is activated when messages and attachments are accessed by any client or agent.
1. Item’s virus stamp attribute is checked.
2. If item has not been scanned by current virus signature, the item is inserted into queue with high priority. If the item was already in the low priority queue, its priority is upgraded.
3. The scanner works its way through queued items, scanning each as it is dequeued. When an item is scanned, it is stamped with a property that marks it as OK, so it will not have to be scanned again. If item was already in low-priority queue when accessed, priority is upgraded to high.
4. Client waits to be signaled when scanning is complete or times out.
Proactive scanning: This mode is activated as messages arrive inbound to the Exchange server.
1. Proactively scans messages as they are submitted to Store, Transport Submit, and Client Submittal.
2. Gives item an opportunity to be scanned prior to access (i.e., Message Open).
3. Proactive items receive a low priority:
  - Maximum of 30 low-priority items in queue
  - FIFO-based removal of low-priority items in queue
4. If removed from queue, then item will be scanned when accessed.
Background scanning: This mode of operation facilitates the ongoing scanning of messages. It is primarily used for rescanning data when virus signatures are updated.
1. Opens each MsgFolder Table and walks contents.
2. The ptagVirusScannerStamp attribute is now stamped on Folders, MsgFolder, Msg, and Attachment table entries.
3. New items in folders will be scanned when submitted or accessed.
4. Sleeps until store is restarted or virus interface is updated.

9.6.7 Tackling spam/UCE

Spam is not a new problem, but it is becoming a more visible one. The Radacatti Group estimates that 2 billion spam messages a day clog the Internet. Brightmail, an antispam vendor, estimates that spam has grown from representing less than 8% of Internet mail volume to as much as 36% of volume today. Microsoft says as much as 90% of MSN/Hotmail volume at times can be spam/UCE content (that is estimated to be 2.4 billion messages per day). So why can’t we do more about this problem? If spam traffic is allowed to continue its plague, it will overrun users’ mailboxes and devices and destroy e-mail’s value as a communication medium. The enterprise requirements for antispam are rather cut and dried. First, organizations sometimes fail to be more aggressive with antispam measures because they are concerned about legitimate e-mail being flagged as spam and eliminated. Thus, enterprises require protection measures that minimize the false positives. Another requirement that is emerging is the desire to deal with spam at the gateway. Most enterprises would rather not hassle with spam inside the firewall where it has an adverse impact on network bandwidth and other system resources, as well as user productivity. Finally, enterprises also want a spam protection solution that is easy to manage and administer and one that is also flexible in balancing user, corporate, and legal requirements.

click to expand
Figure 9.8: Proactive virus scanning mode.

click to expand
Figure 9.9: Background virus scanning mode.

click to expand
Figure 9.10: Exchange 2003/ Outlook 2003 end-to-end antispam solution.

For Exchange 2003, Microsoft sought to make great strides in the area of antispam and to put Exchange on par with competitive messaging systems such as IBM Domino, Sun’s iPlanet, and Oracle’s Collaboration Suite. Features built into Exchange 2000/2003 can help you prevent unsolicited mail. In particular, you can prevent mail from being delivered if there is no sender specified or if the mail is from a particular domain or domains. You can perform filtering across all Exchange servers, or you can determine specific SMTP virtual servers that will perform filtering. Figure 9.10 provides a high-level overview of Microsoft’s end-to-end antispam strategy for Exchange 2003 and Outlook 2003. Table 9.11 provides the key antispam improvements added to Exchange 2003.

Table 9.11: Exchange 2003 Antispam Features
Feature/Improvement	Description
No filter on authenticated or trusted connection	Virus scanning still performed, but potential false positives on internal or trusted mail are avoided
Connection filtering	Global allow and deny lists Support for subscribing to third-party “black hole list” services
Sender filtering	Filter messages sent from particular e-mail addresses or domains Filter messages with blank senders Optionally drop connection
Recipient filtering	Filter messages sent to particular e-mail addresses Filter messages sent to unresolvable addresses Drop connection after 20 unresolved addresses Restricted DLs
Antispoofing	Sender filtering Don’t resolve local addresses received over unauthenticated connections Persist original submission method ( anonymous or authenticated)

9.6.8 User education the final key to antispam /antivirus protection

I cannot emphasize strongly enough how far a little user education will go in these instances. Scanning on your incoming SMTP gateway is an excellent method for protecting your organization against attackers like Melissa, WormExplore, and ILOVEYOU. Scanning for attachment content at the SMTP service is the best way to protect your organization. While this is effective, it can’t stop everything. That is why user education is the other pillar that good protection must stand on. For me, it seems rather simple: If you don’t know the person who is sending you an attachment with an *.EXE, *.COM, *.VBS, or other extension, don’t open it! However, not all users know that every VBS file is a potential bomb. Users of our Exchange services must be educated on these finer points and be encouraged to practice the default rule of not opening any attachment of which they are not sure. In recent outbreaks such as the ILOVEYOU virus, the users who were savvy enough not to open up the suspect messages and instead hit the Delete key went about their business as usual. This is a key point. It is not antivirus software by itself that can protect you from these attacks. It is a combination of a well-implemented gateway and store-based scanning process combined with some solid user education practices. Microsoft Outlook is a very rich and powerful client tool (Outlook 2003 provides the latest in antispam/ antivirus features). With this richness and power come some vulnerability that has been exploited by attacks like Melissa and ILOVEYOU. Only through this two-pronged approach can you ensure that your organization is protected. After all, user education is relatively cheap by comparison.

9.6.9 Message content security and authenticity

Message content security is the final point is this chapter’s complete security strategy for Exchange deployments. Unauthorized access and forgery are the threats of concern when we discuss message content security. Based on an organization’s security requirements, message content security may be satisfied with the mechanisms provided by the Windows and Exchange access control features discussed earlier in this chapter. However, if further measures are required, message content security must rely on techniques such as message encryption and digital signatures. In the final section, I will discuss the basics of a PKI (required to utilize encryption and signing), Certificate Services, and Exchange 2000 Key Management Service (and its retirement in Exchange 2003), and how encryption and signing are used to protect against severe threats of unauthorized access and forgery.

Public key infrastructure

The subject of PKIs could warrant many books and papers on its own. In the context of our discussion, I want to provide an overview with emphasis on why is it fundamental to providing message content security for an Exchange environment. Simply put, a PKI is a system of managing secure keys that provides a robust trust mechanism throughout an enterprise, multiple enterprises, or business partners. A PKI functions to provide a process for issuing, distributing, and validating keys and certificates. The important aspects of message content security for Exchange are encryption and digital signing. S/MIME addresses this aspect and require such an infrastructure to be in place. Specifically, S/MIME is a standard (S/MIME version 3 in its current form) that secures e-mail transmissions in an interoperable fashion using X.509 version 3 certificates and that provides authentication and privacy via digital certificates. The digital certificates used by S/MIME enable e-mail to be signed and encrypted so that only the desired recipient can read the message. The signature also provides nonrepudiation of the sender. Of course, there are many third-party free or fee-based products that will provide variants of encryption and signing capabilities for Exchange clients such as Entrust, VeriSign, and freeware-based Pretty Good Privacy (PGP).

Thus, a PKI is a collection of entities that are providing the preceding functions. Figure 9.11 provides a look at a typical PKI design for an Exchange deployment (note that Exchange 2003 no longer provides KMS—this is discussed below). Leveraged for Exchange message content security, a PKI controls issuance, management, and revocation of keys and certificates.

click to expand
Figure 9.11: A simplified PKI design.

Certificate services

A certificate is an electronic credential that authenticates a user on the Internet and on intranets. Certificates ensure the legitimate on-line transfer of confidential information or other sensitive materials by means of public encryption technology. If someone in your organization connects to a Web site or a server in another company and that server has a certificate signed by an authority you trust, you can be confident that the company the certificate identifies actually operates the server. Likewise, servers can use certificates to verify a client’s identity. In either case, you safeguard your intranet against forgery or impersonation by an outside party. Also consider that, by issuing certificates to employees, coworkers, and internal resources, you can verify a user’s identity internally as well.

Certificates are an integral part of message content security because they also allow users to generate digital signatures and encrypt e-mail. Digital signatures not only validate the sender’s identity, they ensure that the message contents have not been altered. No one can tamper with a digitally signed message without detection. When the sender encrypts a message, only the recipient is able to decrypt it and read its contents. Windows Server Certificate Services allow an organization to act as its own Certificate Authority (CA) or as a subordinate CA in a larger CA hierarchy. A CA is an issuer of digital certificates; it provides and assigns the unique strings of numbers that make up the keys digital certificates use. A CA can issue its own certificates to clients and servers and can revoke certificates when the private key associated with the certificate is compromised or when the subject of the certificate leaves an organization. Certificate Services issues X.509 version 3 certificates.

Public keys must be certified by a CA. Any X.509v3-compatible CA can issue certificates to an Exchange organization. A certificate binds the user’s public key to his or her mailbox. Each X.509 certificate include the following:

A unique serial number
The distinguished name of the CA
The name of the user, which is referred to as the subject of the certificate
The validity period of the certificate
Version 3 extensions

Version 3 extensions are the standard certificate format that Windows Server certificate-based processes use. They can include information related to key identifiers, key usage, certificate policy, alternate names and attributes, certification path, constraints, and enhancements for certificate revocation.

With a certificate trust list, an organization can ensure that the CA issuingthe certificate can be trusted, even if the CA is in another organization. This is the most secure way to verify the source of messages sent from another organization. It is also transparent to users—they don’t need to perform any additional steps to send a digitally signed message to a user in a trusted organization. Because certification establishes trust between CAs, security keys sent between users in certified organizations are automatically trusted. On the other hand, if a user receives a digitally signed message from a CA not on his or her certificate trust list, the recipient cannot rely on that signature. Certificate trust lists are maintained by the Windows Certificate Services or a third-party CA.

Revocation checking warns users when they verify signed messages that contain a revoked certificate. Revoking a user’s advanced security is not the same as deleting a user, and you should do this only if the security of the user is compromised; for example, you should consider revoking advanced security if it appears that someone is signing messages on behalf of another user or if someone has gained access to the user’s security file and password. You can enable security again by assigning another temporary token to the user. A revocation list contains the serial number and expiration date of each revoked user’s certificate. For Windows 2000 and Exchange 2000, KMS stores the revocation list in the key management database and then writes it to the AD (as I will discuss below, KMS has been retired in Exchange Server 2003, therefore impacting this process). The revocation list in the directory is then cached on the client and updated daily. You should limit the use of revocation since, as the revocation list grows larger, the client’s advanced security performance degrades because each time the client verifies a message’s signature, it must check the revocation list.

Exchange Key Management Server

Since Exchange 4.0, Microsoft has provided the Exchange Key Management Service (KMS). This was done to provide advanced security functionality features that were not offered in the core operating system. In addition, even in later days when Windows began to provide some base certificate authority features, Exchange KMS provided some additional features above and beyond the core operating system functionality that were necessary to ensure a solid end-to-end secure messaging solution for Exchange Server. KMS features give administrators greater flexibility without compromising the security and reliability of the service. Earlier versions (Exchange Server 5.5) of the KMS managed the certificate trust list. A certificate trust lists keeps track of all trusted CAs, even those that are outside your organization. The Windows CA server now maintains the certificate trust list. Now Exchange administrators can import external certificates to Windows Server Group Policy objects, and from there, certificates are published to the AD. Any computer in the forest running Windows Server can download a certificate and trust it. Windows clients find the certificate trust list on their domain controllers. For clients running earlier versions of Windows, the KMS server publishes the certificate trust list so that Outlook clients can access it whenever encryption is used in messaging. Windows Server or KMS manages the certificate trust list without intervention in either case.

With Exchange 2000, KMS servers work in conjunction with the AD to enable or recover multiple users at once. Administrators are no longer confined to enabling or recovering only one person or an entire recipient container of users. Unlike Exchange 5.5, each session requires you type the administrative passwords only once. With Exchange 2000 Server, you can now have one KMS server for every administrative group in your organization. With Exchange 5.5, you can have one KMS server for each Exchange site.

Another feature of KMS in Exchange 2000 Server is the capability to import or export users from one KMS server to another. If you have a large organization with multiple administrative groups and someone is transferred to another department, you may need to move the user to another administrative group. That may entail moving that user’s keys to a different KMS server. The export-and-import feature makes it possible for you to move one or more person’s keys securely and without risk of misdirection.

So what happened to KMS in Exchange Server 2003?

Exchange 2000 includes the KMS, which works with Windows 2000 Certificate Services to create a PKI for performing secure messaging. With a PKI infrastructure in place, users can send signed and encrypted messages to each other. The KMS included with Exchange 2000 provides a mechanism for enrolling users in Advanced Security and handles key archival and recovery functions. Exchange Server 2003 no longer includes the KMS. The PKI included with Windows Server 2003 now handles the key archival and recovery tasks that were performed by the KMS in Exchange 2000. If you are using secure messaging with Exchange 2000 and KMS, this solution can still coexist with Exchange 2003. However, you will need to maintain an Exchange 2000 server running KMS as part of your Exchange 2003 infrastructure. Alternately, you can upgrade your entire PKI infrastructure to one where all functionality is hosted by the Windows 2003 Server Certificate Server (fully functionality is enabled by a combination of Windows 2003 Server plus the resource kit).

9.6.10 Putting security together

Deploying and managing a secure Exchange environment involves many areas, disciplines, and levels of expertise. In this chapter, we have just scratched the surface and overviewed the big picture of Exchange security. The most important points are two—that we understand the threats to our Exchange environments and that we are aware of and understand the technology available to us to address these threats.

The threats we discussed were DoS, viruses and spam, unauthorized access and information disclosure, and forgery, spoofing, and relay. It is possible that your organization will never be a target for any of these threats. However, the first incident that occurs will usually bring painful awareness of the fact that protective measures are required. As an example, look at how the outbreak of the Melissa virus in 1999 changed our outlook on antivirus solutions. Even now as I write this, Microsoft is under attack by a nasty virus that has not infected Microsoft, but has infected thousands of systems on the Internet. However, the virus spoofs Support@Microsoft.com for both read receipts and reply address—in effect creating a spam storm for Microsoft.

For each of these threats, we have overviewed the most common means of protection. For the DoS attack, the most common point of attack for an Exchange server is via the SMTP service, where an attacker floods or crashes the SMTP server, thereby denying those services to legitimate users. We also saw with the Melissa virus how a virus attack can lead to a DoS situation. To protect against unauthorized access, several protection mechanisms are available such as Windows and Exchange access control methods like the AD, Kerberos authentication, access control entries and lists, policies, permissions, and Exchange roles. Digital encryption and signing provided with a well-designed and managed PKI can also be an added measure against unauthorized access.

For virus and spam threats, many products and solutions from a range of vendors help cover the three perimeters of defense—the client, server store, and gateways. A comprehensive solution coupled with good security measures will counteract most viral infection threats. For organizations threatened by potential forgery of messages and other content, the most common measure available for both internal and external threats is encryption and signing. These threats can be addressed by a superior firewall design and implementation of Exchange Server’s own features provided to protect against this nondestructive but annoying threat.

Many technologies exist to lock down our Exchange environments, and Exchange 2000/2003 improves upon its already excellent built-in security features. Take some time to assess your environment and the threats that are most likely to occur. Careful research, planning, pilot testing, and deployment of rock-solid security measures will help ensure that your Exchange deployment provides maximum reliability.