Lesson 1: Securing Internet Access in Hosted Environments | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Windows 2000 and Exchange 2000 Server provide an impressive set of security features that can help you protect your organization’s resources against attacks over the computer network. However, to reliably shield your corporate network from the hazards of the Internet, extra precautions in the form of firewalls are required. Exchange 2000 Server, especially in a front-end/back-end (FE/BE) configuration, can seamlessly integrate with sophisticated firewall topologies.

This lesson explains how to secure the Internet access points of an Exchange 2000 organization by means of firewalls, blocking potential attackers while allowing authorized users to access mailboxes and public folders. You can read about firewall configurations in FE/BE arrangements, as well as encryption technology, to secure the Internet-based client communication. You can also read about options to support MAPI-based clients, which, unfortunately, cannot benefit from FE/BE deployments.

After this lesson, you will be able to

Secure a messaging organization by means of sophisticated firewall configurations
Decide whether to use VPNs and the Internet Authentication Service (IAS) to support mobile users and remote locations over the Internet
Enable encrypted communication between clients and FE servers, as well as FE and BE servers
Design secured Internet access points for Exchange 2000 organizations

Estimated time to complete this lesson: 90 minutes

Understanding Firewalls and VPNs

Firewalls are essential components in securing communication over the Internet. They not only help protect internal systems from unauthorized use and attacks, but also allow you to control outgoing communications. VPNs, on the other hand, are useful solutions for mobile users who require remote access to the corporate network. Without the expense of long-distance analog phone or leased lines, users working in a remote office, at home, or on the road can establish a connection to a local Internet service provider (ISP) and use the Internet similar to a dedicated wide area network (WAN) link. VPNs can also be used to replace WAN links between remote offices, providing secure communications across a shared network such as the Internet. The communication is encrypted to prevent fraud and eavesdropping.

Protecting Private Networks via a Firewall

A firewall is a security system that prevents Internet users from directly communicating with internal computer systems. As mentioned, you can also control communication from internal users to the public network. All data traffic is routed through a firewall, or an arrangement of firewalls, that monitor the communication and decide whether the data packets are allowed to pass through or should be dropped. Firewalls can also be called proxy servers or bastion hosts—while each of these terms differs slightly in meaning, their functionality overlaps significantly. Figure 9.1 shows a single bastion host shielding a corporate network from the Internet.

Figure 9.1 - An Internet access point protected by a single firewall

You can use firewalls to protect your internal network resources by means of the following features:

Content scanning Allows you to examine the requests and responses within the actual data packets to determine whether these follow the session state and protocol conventions. With content scanning, you can disable specific protocol features, such as the uploading of files to a File Transfer Protocol (FTP) server. Some firewalls also support virus scanning. It is important to note that encrypted communication between the Internet and internal systems effectively disables this feature because the firewall has no way to decrypt the data.
Data packet filtering Allows you to block communication to and from your internal computer systems and services with the Internet. With packet filtering, you can determine which protocols and data packets are allowed to enter and leave your internal private network. Packet filtering ensures that only authorized communication can take place with the Internet.
Network address translation (NAT) Allows you to hide the network addresses of your internal computer systems from the Internet. With NAT, the firewall replaces the internal Internet Protocol (IP) address (source address) in all outbound packets with a public network address, and vice versa. NAT protects against IP spoofing attacks from the Internet, in which data packets are sent to your network with a falsified source address showing a private and trusted IP address.
Stateful inspection of protocols Allows you to verify that the data traffic follows the basic rules of the communication protocols. With stateful inspection you can prevent session hijacking, for example. The firewall tracks the source ports and ensures that the internal system only sends responses to the original ports. When the firewall recognizes an attack, the connection is dropped. You can also set time outs for incomplete session establishments to protect against SYN flood attacks, which are attempts to flood an internal system with incomplete Transmission Control Protocol (TCP) sessions.
Static address mapping Allows you to permanently map private IP addresses to public IP addresses to route incoming packets from the Internet internally to the correct host, such as a Web server or a Network Load Balancing (NLB) cluster of FE servers. With static address mapping, you can advertise internal systems with public IP addresses on the Internet. Static address mapping is a means to hide the actual IP address of Internet-accessible resources from potential attackers.

Connecting Remote Locations via VPNs

VPNs leverage TCP/IP-based networks, such as the Internet, to connect remote clients and offices through an encrypted channel, known as a tunnel or VPN connection (see Figure 9.2). The encryption of network traffic ensures the confidentiality of the data. At the sending station (that is, the VPN client), the IP datagrams are placed in Point-to-Point Tunneling Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP) frames, which in turn are encapsulated into IP datagrams before they are sent over the network. When the data enters the tunnel it is encrypted, and when it leaves the tunnel it is decrypted. The sending and receiving stations are not aware that tunneling took place. PPTP performs the encryption itself; L2TP relies on IPSec for encryption.

VPNs are an excellent solution for supporting users who need full connectivity to the corporate network yet cannot directly connect to the corporate network. VPN connections allow any type of traffic to be tunneled through a corporate firewall and into the corporate network and can have a different set of filtering rules from those applied to other Internet traffic. They encapsulate all datagrams and allow remote users to work as if they are logged on to workstations in the internal network. For example, it is possible to use Messaging Application Programming Interface (MAPI)-based clients, such as Microsoft Outlook 2000, to connect to an Exchange 2000 server over a VPN connection.

Figure 9.2 - Connecting to a corporate network via a VPN

However, VPNs are only as reliable as the underlying network connection. If your users connect to a local ISP by means of a slow dial-up connection, for instance, remote procedure call (RPC)-based communication can be problematic, and this would adversely affect MAPI-based communication. Over slow or unreliable VPN connections, consider using a Terminal Services client to access a Terminal Server in the corporate network that runs the client applications directly in the local area network (LAN) of the Exchange 2000 server.

You can configure the following types of VPN connections:

Point-to-point connection Allows mobile users to establish remote access connections between their workstations and a server in the corporate network, similar to a dial-up connection. You can configure Windows 2000 Server with Routing and Remote Access Service (RRAS) as a VPN server for remote access.
Router-to-router connection Allows you to connect geographically separate networks over the Internet, similar to dedicated WAN links. The calling router acts as the VPN client and the answering router is the VPN server. Windows 2000 RRAS can work as a VPN client and VPN server to support routed connections.

Note

When using Windows 2000 RRAS, creating VPN connections is very similar to configuring dial-up networking clients and demand-dial routes.

Implementing an Internet Authentication Service

Whether you use RRAS or another network access server (NAS) system, it is vital to protect from unauthorized use those VPN connections that provide remote users with direct access to the corporate network. Two important things must come together for this purpose: The system must identify the user, and the user must be authorized to establish VPN connections. You can enable unauthenticated access to a VPN server, in which case users don’t need to provide a logon name or password, but identification still occurs. In Windows 2000, anonymous users are known under the identity of the IAS guest account.

Windows 2000 Server comes with a powerful IAS, a Remote Authentication Dial-In User Service (RADIUS) for centralized authentication, authorization, auditing, and accounting. Any RADIUS-compliant client can communicate with Windows 2000 IAS, which allows you to integrate this service into heterogeneous environments. Windows 2000 RRAS, for example, uses Windows authentication by default, but can be configured to use RADIUS. Your RRAS servers do not need direct connectivity to a domain controller (DC) when using RADIUS (see Figure 9.3).

Figure 9.3 - An example of RRAS integration with IAS

The IAS authentication process is as follows:

The client connects to the RRAS server to establish a VPN connection.
The RRAS server establishes an EAP (Extensible Authentication Protocol), CHAP (Challenge-Handshake Authentication Protocol), MS-CHAP (Microsoft CHAP), or PAP (Password Authentication Protocol) connection to the client (depending on the client’s capabilities) and challenges the client for user credentials, which the VPN client returns to the RRAS server.
The RRAS creates a RADIUS Access-Request, places the user credentials in it, and sends the request packet to the IAS server.
Based on the source IP address and the RRAS server’s digital signature in the packet, the IAS server verifies that the request packet is from a valid RADIUS client. If it isn’t, the IAS discards the request.
The IAS server contacts a DC in the internal network to validate the user credentials. The IAS also checks existing remote access policies and the user’s dial-in permissions to determine whether to authorize the user’s connection request. In the simplest case, you manage remote access permission for each user account individually in the Active Directory Users and Computers console. Remote access policies, on the other hand, provide more flexibility if you need to specify remote access permissions for several users, but require the Windows 2000 domain to operate in native mode.
If the user is authorized to establish a VPN connection, IAS sends a RADIUS Access-Accept packet to the RRAS server; otherwise, it will be a RADIUS Access-Reject packet.
The RRAS server uses the information from the accept packet to establish the VPN connection with the client according to the connection parameters based on the settings in the remote access policy or the dial-in properties of the user account.

For detailed information about RRAS and the IAS, see the Windows 2000 Server product documentation.

Note

The Windows 2000 IAS supports User Principal Names (UPNs), which allows ASPs to provide their customers with logon names that match their e-mail addresses, as explained in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Packet Filtering for Messaging-Related Protocols

Even a simple firewall allows you to configure packet filters to prevent unauthorized data packets and protocols from entering or leaving your internal network. Based on IP addresses and port numbers, you can block communication to specific hosts or services. A packet filter is typically composed of source IP address and source port; destination IP address and destination port; protocol identifier, such as TCP or User Datagram Protocol (UDP); and the action to take if a data packet matches the rule.

For example, in Figure 9.4, you can configure the firewall so that Internet users are able to access only the Exchange 2000 server (SRV-02-EMS, IP address 131.107.3.125). You can further restrict the communication to specific services on SRV-02-EMS. Services are available through ports. For instance, you might allow inbound traffic to use TCP port 80 for Hypertext Transfer Protocol (HTTP)-based communication with the World Wide Web Publishing Service, but block the communication to all other ports. In this case, Internet users can connect to SRV-02-EMS using Microsoft Outlook Web Access (OWA), but other applications, such as MAPI-based, Internet Message Access Protocol 4 (IMAP4), or Terminal Services clients are blocked. Table 9.1 lists the various ports you might want to open on your firewall to allow users and messaging systems from the Internet to communicate with an Exchange 2000 server.

Table 9.1 Important Messaging-Related Protocols and Their Port Numbers

Protocol	TCP Port Number	TCP Port Number with SSL	UDP Port Number
Domain Name System (DNS)	53	—	53
HTTP	80	443	—
IMAP4	143	993	—
Internet Relay Chat	6661–7000	—	—
IPSec (Protocol ID 50)	—	—	500
Kerberos authentication	88	—	88
L2TP	—	—	1701
Lightweight Directory Access Protocol (LDAP)	389	636	—
LDAP (Global Catalogs)	3268	3269	—
NetBIOS over TCP/IP	139 (session services)	—	137 (name services) 138 (datagram services)
Netlogon	445	—	—
PPTP (Protocol ID 47)	1723	—	—
Post Office Protocol 3 (POP3)	110	995	—
Remote Desktop Protocol (RDP) or Independent Computing Architecture (ICA) protocol	3389	—	—
Rendezvous Protocol (RVP)	80	443	—
RPC dynamic ports	1024 and higher	—	—
RPC endpoint mapper	135	—	—
Simple Mail Transfer Protocol (SMTP)	25	—	—
X.400 over TCP	102	—	—

Note

To view a detailed list of port numbers for protocols, services, and applications, open the Services file, which you can find in the \Winnt\System32\ Drivers\Etc folder. The Services text file has no filename extension.

Figure 9.4 - An Internet access point for OWA

Figure 9.4 illustrates the configuration of a firewall rule to allow HTTP traffic to and from an Exchange 2000 server. Note that you need to allow the communication in both directions, so you actually need to configure two filters. In a typical scenario, Web browsers send HTTP requests to TCP port 80 (nonencrypted communication) or TCP port 443 (SSL-encrypted communication). For the local endpoint of the TCP connection, however, the browser may choose a dynamic port number in the range between 1024 and 65,535. Because you don’t know the client port, you need to configure the outgoing filter so that the firewall allows data originating from the server’s TCP port 80 to any station and any port in the public network. You can read more about the configuration of packet filters later in this lesson.

More Info: Force SSL-Encrypted Communication for Outlook Web Access

When you enforce SSL-encrypted communication for HTTP, users must connect to OWA using the https:// protocol identifier. IIS will refuse requests to the standard (non-SSL) port 80 with the following error message: HTTP 403.4 - Forbidden: SSL required Internet Information Services. Unfortunately, users tend to forget to specify https:// instead of http:// in their connection requests. You can suppress the IIS error message and redirect all incoming non-SSL connections on behalf of the users automatically.

To automatically redirect all incoming non-SSL connections to Exchange 2000 OWA to the SSL-based port, follow these steps:

Create an Active Server Page (ASP) for the following Visual Basic Scripting Edition (VBScript) code:

 <%       If Request.ServerVariables("SERVER_PORT")=80 Then           Response.Redirect "https://" & _                  Request.ServerVariables("SERVER_NAME") & _                  "/Exchange/"      End If %>

Save this file as SSLEXCHANGE.ASP in the \Inetpub\Wwwroot directory.
Launch the Internet Service Manager snap-in, and then, in the console tree, expand your IIS server object, expand Default Web Site, right-click the Exchange virtual directory, and then click Properties.
Switch to the Custom Errors tab and double-click on the 403.4 error code.
Under Message Type, select URL, and then, in the URL field, type sslexchange.asp.
Click OK twice, right-click on the server object in the console tree, and then select Restart IIS.
In the Stop/Start/Reboot dialog box, click OK to restart the IIS services. Use Internet Explorer to test the system configuration by connecting to the URL http://<server name>/Exchange. Your browser should be redirected automatically to https://<server name>/Exchange.

You can read more about the configuration of custom error messages in the IIS 5.0 production documentation and online help.

Creating a Demilitarized Zone

Security-conscious organizations consider the configuration shown in Figure 9.4 insufficient because it does not provide separate networks for internal systems and externally accessible servers. In this example, all internal systems use public IP addresses. Further, Internet-accessible resources, such as the OWA server SRV-02-EMS, reside on the same internal network as user systems. No firewall will ever be completely secure, but if an intruder can break through your firewall, all internal systems are open to attack.

To meet stronger security standards, you need to do the following:

Establish a demilitarized zone (DMZ), also known as a perimeter network or screened subnet, between the private area and the Internet to block all direct traffic between the internal and public network. Allow communication to take place only via the systems in the DMZ, as briefly discussed in Chapter 3, "Assessing the Current Network Environment."
Use private network addressing in the internal network. If your users need access to Internet resources, configure proxy systems or a NAT service in the DMZ to relay the communication and replace the private addresses with public IP addresses.
Use private network addressing in the DMZ; place all Internet-accessible resources in it, such as external DNS servers, public SMTP hosts, OWA servers, and so forth; and configure static address mappings for these systems on the outer firewall to replace the private addresses with public IP addresses.

Note

Request for Comments (RFC) 1918 defines three IP address ranges for private network addressing (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), which are neither used nor routed on the Internet. These numbers should be used on internal networks, but all traffic must pass through a NAT server or proxy server with a valid public IP address before accessing the Internet. To obtain public IP addresses, contact the ISP that provides your Internet access.

Common DMZ Architectures

Depending on the level of security your organization requires, you can establish a DMZ using a single firewall with three network cards or two separate firewalls with two network cards each. You can also create a multizone DMZ with several firewalls. A single firewall with three network cards represents the least secure solution because it is physically connected to the private network. A DMZ with two or more separate firewalls is more secure, but more complex and costly than the three-pronged firewall approach. For optimal protection of your Internet access point, consider the installation of dissimilar systems. Dissimilar firewalls usually have different weaknesses, making it harder for an intruder to break through. Figures 9.5 and 9.6 show typical DMZ configurations.

Figure 9.5 - Establishing a DMZ with one or two firewalls

Figure 9.6 - Establishing an inner and outer DMZ with three firewalls

Note

The multizone DMZ is most useful if you need to assign an Internet- accessible system a public IP address. The systems in the inner DMZ can still use private IP addresses if the intermediary firewall provides NAT.

Increasing System Security in the DMZ

You should tightly secure the servers in the DMZ because they are exposed to the Internet. In general, deactivate all those services on these systems that are not required and block all protocols that you do not intend to support over the Internet.

Use the following guidelines to secure your Internet-accessible systems:

Add any root certificate authority (CA) certificates you trust to the security stores of your Internet Information Services (IIS) servers and remove all those CAs you don’t trust. Do not remove Microsoft or VeriSign root CAs because they are required for Windows 2000 CAs. Security certificates are covered in more detail in Lesson 2.
Consider the configuration of an IPSec packet-filtering policy on ever exposed Windows 2000 server to implement multiple levels of security in the DMZ.
Consider the implementation of a professional intrusion detection system in the DMZ to identify potential security incidents as early as possible.
Deactivate all server services and block all TCP/IP protocols other than those you explicitly require. If you want to use SSL to secure the client communication, do not stop the Windows 2000 License Logging Service on the FE server. Without this service, the IIS does not allow more than 10 simultaneous SSL connections.
Deploy redundant IIS servers in a load-balancing cluster, such as multiple Exchange 2000 FE systems. This can help to mitigate the risk of denial-of-service attacks in which an attacker attempts to disrupt normal server operations. An attacked system might become completely unavailable, but the other nodes in the load-balancing cluster might be able to take over the client connections. However, it is possible to attack all systems in a cluster at once and, even if you distribute the site geographically, your systems remain vulnerable. NLB can help to mitigate, but does not prevent, denial-of-service attacks. The advantages of NLB are discussed in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."
Deploy SMTP relay hosts with anti-virus and anti-spam software to check all incoming SMTP messages for dangerous attachments and block unsolicited commercial e-mails. Create corresponding mail exchanger (MX) records for your public SMTP hosts in the external DNS servers with the same or different priorities.
Disable the use of IP addresses in content-location headers of HTML pages. On your Windows 2000 IIS server, access the \Inetpub\Adminscripts directory, type CSCRIPT ADSUTIL.VBS set w3svc/UseHostName True , press Enter, and then use the Internet Services Manager console to restart IIS.
Enable protocol logging for all services exposed to the Internet, and make sure the Everyone account does not have Modify or Delete permissions to the IIS log files (\Winnt\System32\LogFiles directory) to prevent attackers from deleting the files to cover their tracks.
Install the newest service packs and hot fixes when they become available. Security breaches often exploit vulnerabilities exposed through software bugs. Microsoft continuously searches for security weaknesses and releases corresponding hot fixes that are incorporated into new service packs. Remember to carefully test each service pack and hot fix before installing it on a production system because third-party applications might not function correctly with new versions.
Make sure all disk partitions are formatted with the NT file system (NTFS) and verify or adjust the NTFS file permissions on virtual directories to grant only the required users access permissions. By default, the Everyone account has full control to most directories, which is an insecure configuration. This account should not have Write permissions to the directories on the partitions where the operating system and IIS are installed. If you need to grant the Everyone user write access to a folder, you should apply disk quotas to prevent users from uploading data up to the capacity of the system volumes. If possible, create a separate volume for folders that allow Write access to the Everyone account.
Make sure the \Winnt\System32\Inetsrv\Iisadmpwd virtual directory does not exist because it allows users to reset Microsoft Windows NT and Windows 2000 passwords. This directory should only be available on internal Web servers in the private network that are not accessible from the Internet.
Remove all sample applications and unnecessary Component Object Model (COM) components that exist on the IIS server.
Use the Internet Services Manager console to edit the properties of your HTTP virtual servers, remove all unused script mappings, and deactivate the use of parent paths.
Use the security template HISECWEB.INF, which you can download from Microsoft’s Web site (www.microsoft.com ), to configure system-wide Windows 2000 settings.

Tip

You can stay informed about security issues as they arise by subscribing to the Microsoft Security Notification Services, which is an e-mail-based information service. For more information, go to the Microsoft Web site (www.microsoft.com ) and search for the phrase "Security Notification Services."

Increasing the Security of External SMTP Hosts in the DMZ

You can use FE servers or other Exchange 2000 servers as SMTP relay hosts in your DMZ, which provides you with the ability to control incoming and outgoing message transfer based on SMTP virtual servers and SMTP connectors. The design of message routing topologies is discussed in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

SMTP systems exposed to the Internet have specific configuration requirements. Among other things, you should not allow anonymous relaying of SMTP messages through your smart hosts. Otherwise, anyone who wants to send unsolicited commercial messages to thousands of users can misuse your systems. An advertiser would only need to configure his or her Internet mail client to send messages to your SMTP host if it accepts message relaying for anybody. The advertiser composes one new message, conveniently specifies thousands of recipients from a database, and then sends this message to your relaying host. The client’s job is quickly done. It is your SMTP host that has to do all the work of sending the unsolicited message to thousands of users over the Internet. Fortunately, Exchange 2000 Server does not allow anonymous relaying by default. To make sure it is disabled, open the Exchange System Manager snap-in, display the properties of your SMTP virtual server, click the Access tab, click Relay, and then, in the Relay Restrictions dialog box, make sure only authenticated users are able to relay messages.

You can also prevent the reception of unsolicited commercial messages with message filters. This is highly recommended, because delivering unnecessary Internet messages is a drain on your system resources. In addition, there is always a risk of receiving viruses contained in message attachments. To prevent the delivery of messages from specific sources, launch the Exchange System Manager snap-in. Display the properties of the Message Delivery object, which can be found under Global Settings. Click the Filtering tab, and then click Add to specify the senders that you want to filter out. As soon as a filter is defined, you can activate the filtering feature on your virtual server. Display its properties, then, in the General tab, click Advanced, edit the IP Address – TCP Port mapping, and select the Apply Filter check box. If a message is received with a sender e-mail address that matches a filter entry, the message is discarded.

It is also possible to block message reception from specific hosts, a range of computers, or entire SMTP domains. Display the properties of the SMTP virtual server one more time, click the Access tab, click Connection under Connection Control, and then, in the Connection dialog box, make sure the All Except The List Below option is selected. Click Add, and specify the unwanted computer’s IP address or a range of IP addresses. If you activate the Domain option, on the other hand, you need to specify a complete SMTP domain name, such as adventure-works.com. Remember that reverse DNS lookups must work for the DNS name; otherwise the server cannot obtain the IP addresses that should be denied access.

Securing the Internet Access Point of an Exchange 2000 Organization

Exchange 2000 Server, specifically the FE/BE architecture, is perfectly suited for tiered firewall arrangements. In a nutshell, place the FE server in the DMZ, allow your users access to only this system through the outer firewall, and open the inner firewall only for incoming requests from the FE server. Your users can work with their mailboxes and public folders. The FE server relays the client communication through the inner firewall to an appropriate BE server, as explained in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server." Users do not need to pass through to the corporate network directly.

Configuring the Outer Firewall

Figure 9.7 illustrates the configuration of an outer firewall with static address mapping for the servers in the DMZ. OWA, IMAP4, and POP3 clients communicate with the FE server in encrypted form. Keep in mind that the latter two require an SMTP relay host to send messages. Optionally, you might also want to open TCP port 3269 to support SSL-based LDAP communication with Global Catalogs (GCs), but keep in mind that this can expose sensitive organizational information. IMAP4 and POP3 clients do not necessarily require access to the GC.

Enabling SSL-Based Encryption on FE Servers

In an FE/BE configuration, users can only log on to Exchange 2000 Server using basic authentication mechanisms, which require the transmission of user name and password in clear text over the public network. Furthermore, communicating with FE servers and SMTP hosts in nonencrypted form allows eavesdroppers to intercept and read all messages. For these reasons, it is unacceptable to allow nonencrypted communication with FE systems across public networks. If you cannot deploy VPN connections or use IPSec to secure the client communication, you must enable and enforce SSL-based encryption on all protocol virtual servers and open only the SSL-specific ports on the firewall, as shown in Figure 9.7.

SSL relies on public key encryption. The encryption keys are automatically exchanged in the form of an X.509 certificate during the security handshake. Therefore, to enable the SSL-based encryption, you first need to install a server certificate in the virtual servers. Use the Internet Services Manager console for the default HTTP virtual server or the Exchange System Manager snap-in to install the server certificate. You can request a certificate from a CA on the Internet or use a private certificate server. Public key encryption is covered in more detail in Lesson 2.

Figure 9.7 - Internet connections to an FE server with static address mapping

You might also want to encrypt the communication from Internet-based messaging clients to the SMTP relay host, but the SMTP service of Exchange 2000 Server does not support SSL. Netscape has defined TCP port 465 for SSL-encrypted SMTP, but when you configure your IMAP4 or POP3 client to communicate by means of SSL, you will receive an error message indicating that the communication with the SMTP host failed. The Exchange 2000 SMTP service monitors TCP port 25 and only understands Transport Layer Security (TLS), which is a slightly different security protocol. Microsoft Outlook Express 5.0 and later versions support TLS to send messages in encrypted form via the Exchange 2000 SMTP service. If you need to support TLS-unaware clients, consider VPN connections or IPSec, or install an SMTP relay host in the DMZ that supports SSL-encrypted SMTP.

Note

Encrypting the client communication prevents the outer firewall from checking the contents of data packets. It is impossible, for instance, to check for viruses.

Configuring the Inner Firewall

Configuration of the inner firewall is more complex because you need to ensure that the FE server can communicate with all required systems in the corporate network, including BE servers, DCs, and GCs. Table 9.2 summarizes the required ports that you need to open between the DMZ and the internal network to allow FE servers to function properly.

Table 9.2 Required Ports for FE/BE Communication

Port	Transport	Service	Comments
25	TCP	SMTP	You need to open this port to allow the SMTP relay host in the DMZ to communicate with at least one Exchange 2000 server in the private network. To increase security, you can require authentication between the servers. Another option is to use X.400 connectors instead of SMTP, which would require you to open TCP port 102 for X.400 over TCP.
80	TCP	HTTP	If users work with OWA, you need to open the default HTTP port. Keep in mind that SSL encryption or custom ports are not supported between FE and BE servers, as discussed in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."
110	TCP	POP3	Same issues as with HTTP. Only the default port is available for FE/BE communication.
143	TCP	IMAP4	Same issues as with HTTP. Only the default port is available for FE/BE communication.
53	TCP	DNS	The FE servers must be able to resolve the names of internal systems into their corresponding IP addresses, otherwise, communication with BE servers cannot take place.
53	UDP	DNS	Ideally, the FE servers can access an internal DNS server through the inner firewall to locate DCs and GCs and obtain all required IP addresses. If this is not possible, you need to specify the GCs in DSAccess Registry keys, as explained later. You also need to specify the IP addresses of all Exchange 2000 servers, DCs, and GC servers in the FE servers’ HOSTS file. Make sure that this information is always updated. Name resolution mechanisms are discussed in Chapter 3, "Assessing the Current Network Environment."
389 3268 88 88	TCP TCP TCP UDP	Active Directory (DC) Active Directory (GC) Kerberos authentication	FE machines must belong to the same organization as the BE servers and must authenticate themselves using their local system account to successfully communicate with the Active Directory service. Exchange 2000 Server performs this authentication via Kerberos, which is the native BE servers and must authenticate themselves using their local system account to successfully communicate with the Active Directory service. Exchange 2000 Server performs this authentication via Kerberos, which is the native authentication protocol of Windows 2000 Server.
135 445 1024+	TCP TCP TCP	RPC endpoint mapper Netlogon Dynamically assigned ports	To authenticate users, FE servers must be able to locate DCs and communicate with Active Directory via RPCs. RPC- based communication, however, uses dynamic port mappings by default. To determine the required endpoint, the FE server contacts the RPC endpoint mapper on the DC at the well-known TCP port 135, which returns the desired information. The RPC-based communication with Active Directory can then take place. Dynamic ports are difficult to handle in packet filters. Fortunately, you can configure a static TCP port for Active Directory. Use the Registry Editor to add a DWORD value called TCP/IP Port to the following location and define the desired port number in decimal format (if possible, assign a port number higher than 5000, because the system itself prefers to use the ports from 1024 to 5000 for dynamic assignments): HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NTDS \Parameters

Note

The FE server must contact the RPC endpoint mapper whether the port assignment is dynamic or static.

Disabling Client Authentication

Cautious administrators might refuse to allow communication to the RPC endpoint mapper (TCP port 135) through the inner firewall because this might provide an avenue for denial-of-service attacks. However, if TCP port 135 is blocked, the FE server cannot communicate with Active Directory to authenticate users. Fortunately, it is easy to address this issue on the FE server. Disable any authentication mechanisms in the protocol virtual servers and enable anonymous access. This is not a security problem because the FE server does not contain any data and the BE server performs the authentication in any case. The user is unknown to the FE system, which prevents implicit Uniform Resource Locators (URLs) from working in OWA, but access to mailboxes is possible using explicit URLs. Access to public folders does work as discussed for alternate public folder hierarchies in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Note

If RPC-based communication is not supported, stop all Exchange 2000 services, including System Attendant and Information Store on the FE servers. Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server," contains detailed information about how to accomplish this.

Addressing Active Directory Service Discovery Problems

More complicated is the DNS access situation. Security policies may disallow systems in the DMZ access to internal DNS servers, but FE servers must query DNS for service (SRV) records to locate DCs and GCs. If TCP and UDP ports 53 are closed on the inner firewall, you must manually provide a list of servers and specify IP addresses in the HOSTS file, as mentioned earlier.

To specify a DC for retrieving configuration information, create (or open) the following Registry key on each FE server, and configure a REG_SZ value called ConfigDCHostName as well as a REG_DWORD value called ConfigDCPortNumber. Set ConfigDCHostName to the fully qualified domain name (FQDN) of the host preceded by two backslashes, such as \\SRV-01-DC.adventure-works.com. Set the ConfigDCPortNumber value to 0x185. 0x185 is hexadecimal for 389, the TCP port number LDAP uses.

 HKEY_LOCAL_MACHINE \SYSTEM  \CurrentControlSet  \Services  \MSExchangeDSAccess  \Instance0

To specify a GC for address book lookups, create (or open) the following Registry key, and configure a REG_SZ value called UserGC1 as well as two REG_DWORD values called PortNumber and IsGC. Set UserGC1 to the FQDN of the host preceded by two backslashes, such as \\SRV-01-GC.adventure-works.com. Set the PortNumber value to 0xCC4 and IsGC to 0x1 to identify the server as a GC.

 HKEY_LOCAL_MACHINE \SYSTEM  \CurrentControlSet  \Services  \MSExchangeDSAccess  \Profiles    \Default

Note

Specifying DCs and GCs manually allows you to streamline the RPC communication through the inner firewall. The FE server attempts to communicate with those servers found in the MSExchangeDSAccess Registry key before attempting standard DNS lookups.

Securing the FE/BE Communication

It is not possible to encrypt the communication between FE and BE servers using SSL. However, this does not mean that you cannot protect messages and data between the DMZ and the internal network. This might be required, for example, if inner network segments are considered insecure, in which case Microsoft recommends encrypting the communication using IPSec, provided that all servers are running Windows 2000 Server. Among other things, IPSec allows you to support RPC-based communication across the inner firewall without opening TCP port 135 for the RPC endpoint mapper.

IPSec is an Internet standard developed by the Internet Engineering Task Force (IETF) that defines two protocols for protection of data traffic. The first protocol, Authentication Headers (AH), provides authentication, integrity, and anti-replay protection. AH allows you to reliably authenticate computers and prevent tampering with data, but it doesn’t encrypt the information. The second protocol is Encapsulating Security Payload (ESP), which, as its name implies, encapsulates (and encrypts) the header information and the data included within the IP packets. When AH and ESP are combined, they provide authentication, integrity, and anti-replay protection, plus data encryption services. To secure the communication between the internal systems and the servers in the DMZ, you need to use ESP. The encapsulation of IP datagrams is transparent to the applications, such as the HTTP, IMAP4, or POP3 services. Applications are not aware of the encrypting and decrypting processes because it is handled within Windows 2000’s TCP/IP stack.

To enable IPSec, you need to apply security policies to the FE and BE servers by following these steps:

Launch the Network and Dial-Up Connections tool from the Control Panel, right-click the desired Local Area Connection, and then select Properties.
In the Local Area Connection Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.
Click Advanced and then click the Options tab. Under Optional Settings, select IP Security, and then click Properties.
In the IP Security dialog box, enable the Use This IP Security Policy option and select a desired IPSec policy from the drop-down list.

For BE servers, the Client (Respond Only) policy, included in Windows 2000 Server, is appropriate. Based on this policy, BE servers can respond to requests for IPSec communication from FE servers. Internal systems, such as MAPI-based clients, can continue to communicate with the BE servers in nonencrypted form (see Figure 9.8). On FE servers, on the other hand, you might want to use the Server (Request Security) policy, which stipulates that security is always requested for all IP traffic, but unsecured communication is allowed with systems that do not respond to the request. If this standard policy does not meet your requirements, use the IP Security Policy Management snap-in to create a custom IPSec policy. Microsoft provides a policy file specifically configured for FE servers, which you can download from Microsoft’s Web site (www.microsoft.com ). Search for the phrase "FEBE_SUP.EXE." You can read more about IPSec in the Windows 2000 Server product documentation.

Figure 9.8 - IPSec communication across the inner firewall

To support the communication between the DMZ and the internal network, allow the following IP protocols and UDP ports on the inner firewall:

Protocol ID 50 Allow this protocol to support inbound and outbound ESP traffic.
Protocol ID 51 Allow this protocol to support inbound and outbound AH traffic.
UDP Port 500 Open this port to support inbound and outbound Internet Key Exchange (IKE) traffic.

Note

Many NAT servers cannot forward IPSec encrypted data successfully, so verify that your firewall supports IPSec through NAT before attempting to implement the two together.

Supporting MAPI-Based Clients Through Firewalls

Recall that MAPI-based clients cannot benefit from FE/BE arrangements and always require direct connectivity to the mailbox and public folder servers. This is a problem if you want to support Outlook users over the Internet. Among other things, you would have to expose the BE servers to the public network by opening the TCP ports for RPC-based communication (that is, TCP port 135 and TCP ports 1024+) on both the inner and outer firewalls. Bear in mind that MAPI-based clients need direct RPC connectivity to a mailbox server and public folder servers and also to the GC.

To at least avoid opening all client ports (1024+), you can assign Active Directory and the Information Store static TCP ports. This was already explained for Active Directory. To assign the Information Store a static port, open the following key, add the TCP/IP Port DWORD value (note that there is a space between TCP/IP and Port), and specify a desired port number in decimal format (use a port number higher than 5000):

 HKEY_LOCAL_MACHINE \SYSTEM  \CurrentControlSet  \Services    \MSExchangeIS  \ParametersSystem

You have to restart the Information Store for the changes to take effect.

Generally, organizations do not support MAPI-based communication through firewalls. Alternatives are the deployment of VPNs to support MAPI-based clients from remote locations, use of Terminal Services clients, or both. VPN connections provide a sufficient level of security without TCP port restrictions. Terminal Services clients, on the other hand, only need to communicate via TCP port 3389 with a Terminal Server.

Figure 9.9 shows an example of a combined VPN, Terminal Services, and Outlook 2000 solution. The user connects to the VPN server via PPTP, and when the VPN connection is established, he or she can connect to the Terminal Server. The user then launches Outlook 2000 on the Terminal Server and can access the mailbox server via the IPSec tunnel through the inner firewall.

Figure 9.9 - Supporting MAPI-based clients by means of VPNs and Terminal Services

Designing a Secure Internet Access Point for Wide World Importers

Wide World Importers, introduced in Chapter 1, is a fictitious international corporation with headquarters in New York and 400 offices and agencies in 60 countries. Wide World Importers is one of the world’s leading steel importers, with 45,000 employees. The company has successfully upgraded all messaging systems in New York to Exchange 2000 Server and is now evaluating ways to provide mobile users, such as sales representatives, with a reliable and secure solution for remote access. "Our mobile users usually work with Outlook 2000 or Microsoft Outlook XP, but we also want to support Outlook Web Access over the Internet," says Barbara Hoffman, Senior Manager of the Information Systems Department. "This will allow our sales representatives to access information everywhere, such as on a kiosk computer in an airport, or on their cellular phones using the Microsoft Mobile Explorer Micro Browser. I have asked Peter Waxman, Head of Communications Technology, to design a secure solution for us."

Waxman suggested the following strategy to secure the New York Internet access point of Wide World Importers:

Wide World Importers is a well-known company, but as a steel importer, it is certainly less visible on the Internet than software companies, such as Microsoft, or financial institutions, like Woodgrove Bank. A DMZ with two bastion hosts should provide sufficient security for our Internet access point. We will use a UNIX-based firewall system on the Internet side and a different firewall product on a Windows 2000 server on the internal side of our DMZ.
We need to support Outlook 2000 and Outlook XP clients, but it is not feasible to allow RPCs across the firewalls. For this reason, we will deploy a VPN for remote access based on PPTP to a VPN server in the DMZ. To avoid licensing and other expenses for a Terminal Services solution, our mobile users will run Outlook directly on their client PCs. If connections are unreliable or slow, OWA can be used instead of Outlook.
To provide access to OWA, we will install two FE servers in an NLB cluster in the DMZ. We still need to decide whether to obtain a server certificate from an official CA or implement our own PKI with a root CA. In any case, a server certificate is required to enable SSL-based communication to HTTP virtual servers. All IIS services, other than the World Wide Web Publishing Service and dependent services, must be disabled on the FE servers. On the Internet side of our DMZ, only SSL-based HTTP via TCP port 443 should be allowed.
OWA users do not require direct access to an SMTP service to send messages. For inbound and outbound message transfer, however, we will deploy dedicated SMTP relay hosts and create multiple corresponding MX records in our public DNS zone.
To provide optimal security between FE and BE servers, and to support RPC-based communication with the internal network, we will enable IPSec between all systems in the DMZ, including FE servers, VPN servers, SMTP relay hosts, and our internal network.

Activity: Designing Security for Internet Access Points

In this activity, you will decide how to implement secure Internet access points for two companies that plan to provide flexible access to Exchange 2000 resources. The companies are Northwind Traders and Proseware, Inc., introduced in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Tip

You can use Figure B.25 in Appendix B as a guideline to accomplish this activity.

Scenario: Northwind Traders

Northwind Traders has deployed Exchange 2000 Server in its data center in Los Angeles, California, and has configured numerous virtual messaging organizations for its trading centers all over the United States. Internally, the users in the data center work with Outlook XP. The trading centers, on the other hand, use only OWA for messaging. To support the users in each trading center, Northwind Traders has installed several FE servers in a load-balancing cluster and configured a separate HTTP virtual server for each virtual organization. Each trading center has its own Internet domain, which the data center has officially registered with the Internet authorities.

"Among other things, we have created virtual organizations to cut costs," says Mark Harrington, Head of Information Technology. "We cannot exceed the budget with an ambitious arrangement of firewalls. I don’t think Northwind Traders is an attractive target for Internet criminals."

It is your task to outline an appropriate firewall configuration for Northwind Traders:

According to Harrington, only a limited budget is available for firewalls. Which configuration would you recommend?
Does Northwind Traders need to support MAPI-based clients over the Internet?
Northwind Traders has deployed FE servers and SMTP relay hosts in the DMZ. How do you need to configure the World Wide Web Publishing Service, IMAP4, POP3, and SMTP services on the FE servers?
The trading centers of Northwind Traders operate independent LAN environments connected to the Internet through dial-up connections to a local ISP. Windows 2000 Server with RRAS is used as dial-up router. How can you best connect the trading centers to the FE servers in the data center?
Do you need to enable TLS on the SMTP relay hosts in the DMZ?
Northwind Traders intends to provide the trading centers with a simple URL for mailbox access. How do you need to configure the systems in the DMZ and internal network to achieve this without opening RPC-based ports on the inner firewall?

Scenario: Proseware, Inc.

Proseware, Inc. has installed 28 FE servers to support more than 350,000 private OWA users. According to Guy Gilbert, Head of IT Operations, security is a paramount goal at Proseware. "We have deployed a sophisticated infrastructure of firewalls to protect our front-end servers," he says. "The question is not how to provide access to these systems from the Internet. We use SSL and allow communication to the front-end servers only through TCP port 443. The question is how to achieve a secure communication to the back-end servers. We do not plan to support IPSec on the inner firewall, do not want to allow access to internal DNS servers, and by no means want to open port 135 on the firewalls to our internal network."

It is your task to outline an appropriate FE/BE communication strategy for Proseware, Inc.:

How does Proseware have to configure the FE servers in this scenario?

Lesson Summary

If you plan to connect an Exchange 2000 Server organization to the Internet, you have to manage a significant level of security risk, which requires you to deploy an infrastructure of firewalls. Firewalls and encryption technology are essential elements in securing communication over the Internet.

For optimal protection, establish a DMZ between the Internet and your internal network. At a minimum, this requires a firewall with three network cards. A more secure solution would include two or more dissimilar firewalls. You should only allow communication from the Internet to the systems in the DMZ, not to the internal systems. FE servers should be located in the DMZ. To provide adequate security, encrypt the communication over the Internet. Otherwise, user accounts, passwords, and messages are transmitted in clear text. If you do not want to enable SSL encryption, use a VPN or IPSec.

Configuration of the inner firewall is more complex because you need to ensure that the FE server can communicate with all required systems in the internal network. Depending on the configuration, FE servers may have contact with internal DNS servers, BE servers, DCs, and GCs. If internal DNS information is unavailable, you need to register a list of DCs and GCs as well as the IP addresses of all relevant servers manually on the FE servers. Furthermore, if FE servers are supposed to authenticate Internet users, RPC-based communication with Active Directory must work. If you cannot open the required ports on the inner firewall, disable the authentication or enable IPSec on the FE and internal servers and open the inner firewall for IPSec-encapsulated IP frames.