Better Together: ISA Server 2000 and Microsoft Exchange Server 2000/2003

 

Email is the engine driving today’s business. While most businesses can go a day or two without the corporate Web Server, FTP Server or even file server, a one or two day loss of email access can often prove to be catastrophic. Even when the mail servers are humming along without fail, lack of access can prove devastating. An innocent day away from the office, and from the office email, might lead to a lost meeting, a lost lead, and a lost opportunity.

 

Remote access to Exchange Server services is a powerful weapon against lost opportunity. No longer does a day away from the office mean a day away from business critical email.  Just pull out the trusty PDA, Internet enabled cell phone, or laptop and connect to your office mail. If something important comes up you can respond right away from anywhere in the world.

 

This ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document focuses on why ISA Server 2000 provides the ideal firewall solution for allowing remote access to your Exchange Server. Subjects covered in this document include:

 

 

The Challenge of Secure Remote Access and Traditional Firewalls

 

Just about any firewall can be used to provide remote access to your email located on a Microsoft Exchange Server located on the internal network. The real challenge is to allow secure remote access to Exchange email services. Secure remote access means configuring the firewall to forward inbound connection requests from remote hosts to your Exchange Server on the internal network in a way that allows the greatest level of access with the highest level of security.

 

There are several ways you can allow inbound access to Exchange Services on the corporate network. Traditional firewalls use a method typically referred to as “port forwarding”. The firewall accepts inbound connection requests from an email client on the Internet on a predefined IP address and port, and forwards those requests to the Exchange Server on the internal network.

 

For example, a remote email client needs to download mail via the POP3 protocol. You configure the firewall to accept incoming connections on TCP port 110 and then forward the connection to TCP port 110 on the Exchange Server on the internal network. This port forwarding approach is akin to simple packet filtering that traditional firewalls find as their stock-in-trade.

 

The problem with this simple port forwarding approach used by traditional firewalls is that it does nothing except prevent inbound connection requests to unapproved ports, and for approved ports, the firewall just forwards the connection request and passes the packets. The traditional firewall doesn’t evaluate the validity of the messages moving between the email client and Exchange Server; it doesn’t know how.

 

Hackers, viruses, worms and an entire array of mail-related exploits take advantage of the traditional firewall’s inability to evaluate the validity of the information it passes into the corporate network. The solution to this problem is the modern application layer aware firewall.

 

Modern Application Layer Aware Firewalls Come to the Rescue

 

Modern firewalls use Application Layer Filtering methods to examine the Application Layer (also known as “layer 7”) contents of the communication. The application layer contains the commands and the data transferred between the client and server applications.

 

The application layer aware firewall is able to perform the same type of port forwarding as the conventional firewall, but it is also able to inspect and evaluate the communications moving between the email client and Exchange Server. In our POP3 example, the application layer aware firewall can check for valid POP3 commands so that attackers can use exploits like a buffer overflow attack against the internal network’s Exchange Server. The attack is thwarted at the firewall.

 

The day of the conventional firewall is over. TCP/UDP port based access control is inadequate in today’s complex network services environment. Any port can be used to host any service, and alternate protocols can be used to “wrap” and “transport” other protocols.

 

An example of this “wrapping” is the RPC over HTTP protocol that allows Exchange RPC Messages to be wrapped inside an HTTP message for passed through firewalls. The RPC over HTTP protocol allows the full Outlook MAPI client to access the Exchange Server and benefit form all Exchange Server services and features.

 

Another example of such protocol wrapping is a group of services that provide “HTTP tunneling”. The purveyors of these services advertise the fact that the user can bypass firewall security and “tunnel” any protocol and application through TCP port 80 (port 80 is legitimately used for Web access) with the use of their software. If your organization sets tight outbound access policies, users can subvert them using these tunneling services. Most firewall administrators block IRC access because of the strong security risk that protocol represents. The HTTP tunneling services allow the users to tunnel their IRC connection inside TCP port 80. The traditional firewall using port based access control passes the packets because it is completely unaware of the application layer data contained inside the HTTP communication.

 

ISA Server 2000 solves the problem of secure remote access to Exchange Services because of its sophisticated layer 7 awareness. In fact, ISA Server 2000 should be considered the model for application layer firewalls because of its progressive access control and connection inspection mechanisms. A properly configured ISA Server 2000 firewall is one of the most powerful tools at your disposal for preventing unauthorized inbound and outgoing access, to and from the internal network.

 

In addition, the properly configured ISA Server 2000 firewall provides a detailed audit trail that allows you to perform detailed forensic analysis should that need ever arise. The Web Proxy, Firewall and IP Packet Filter logs contain a goldmine of information regarding who connected to the firewall, when the connection was made, and what happened to the connection and what passed through the connection.

 

Unique Advantages to Using ISA Server 2000 Firewalls to Protect Exchange Server 2000/2003

 

An ISA Server 2000 firewall protects Exchange Servers on your internal network using several unique features that you won’t find on any other firewall in ISA Server 2000’s class:

 

 

 

Let’s look at each of these unique advantages to using ISA Server 2000 to protect Exchange Servers in more detail so that you get a better idea of the very high level of security ISA Server firewalls provide, while at the same time enhancing the email experience for remote workers.

 

Secure Remote Access for the Full Outlook MAPI Client

 

Traveling and other off-site employees need to access the Exchange Server using the same device when they’re at the office and when they’re on the road. The device could be a laptop computer, a PocketPC or a mail enabled phone. Organizations that have standardized on the full Outlook 2000/2002/2003 MAPI client can use the full array of options and services provided by Microsoft Exchange. The full MAPI client provides the richest email experience for Outlook users and these users develop a strong attachment to the full functionality provided by the full Outlook MAPI client.

 

A frequently encountered problem is that depending on their location, users must change between the full Outlook MAPI client and Outlook Express. They can connect to the Exchange Server and use the full Outlook MAPI client when connected directly to the corporate network, but when on the road, they must use Outlook Express because traditional firewalls cannot be configured to allow secure inbound access for the full MAPI client.

 

Microsoft KB article XCCC: Exchange 2000 Windows 2000 Connectivity Through Firewalls describes static port assignments required to allow inbound access for the full Outlook MAPI client through a traditional firewall. The static packet filters required create an unacceptably insecure firewall configuration because they allow inbound access to core Active Directory related services. An even greater problem is that traditional firewalls do not understand the commands passed between the full Outlook MAPI client and the Exchange server and can’t assess the validity of these commands. Traditional firewalls will pass exploit code to the Exchange Server because they don’t understand the RPC application layer protocol.

 

The solution is ISA Server 2000 secure Exchange RPC Publishing. Secure Exchange RPC publishing leverages the ISA Server 2000 RPC Application Filter to provide an exceptionally secure remote access solution for the full Outlook MAPI client. The secure RPC Application Filter inspects and manages communications between the full Outlook MAPI client and the Exchange Server. Only valid connections requests and commands are honored; invalid connections attempts and exploits are dropped at the network perimeter by the ISA Server firewall.

 

Secure Exchange RPC Publishing requires no statically opened ports on the ISA Server 2000 firewall. You create a secure Exchange RPC Server Publishing Rule allowing inbound connection requests from remote Outlook MAPI clients. The requests are forwarded to the Exchange Server on the internal network. Only TCP port 135 is open and the secure RPC application filter guards this port. Only valid Exchange RPC messages are allowed.

 

ISA Server 2000’s secure RPC Publishing represents a rare example where security and functionality are directly related. In almost all computer networking contexts, security and functionality are inversely related; the more secure the solution, the lower the level of functionality and usability provided to users. In contrast, secure Exchange RPC publishing provides a higher level of security and a higher level of functionality than any other remote access solution for the full Outlook MAPI client.

 

Worms that exploit issues with Windows RPC mechanisms reveal the best example of the security provided by ISA Server 2000’s smart RPC filter. Organizations that allowed remote access for the full Outlook MAPI client via any other firewall were at risk of being infected by the Blaster worm and its variants. No other firewall was able to evaluate the nature of the RPC connection request. Non-ISA Server 2000 firewalls passed the RPC connections requests directly to the Exchange Server without inspection or evaluation by an intelligent application layer filter. The result was that unpatched Exchange Servers were infected with the Blaster worm and suffered downtime and potential data loss because they did not use a secure ISA Server 2000 firewall.

 

Organizations using ISA Server’s secure Exchange RPC publishing were completely protected from external attack. Even unpatched Exchange Servers were immune from external attack by the blaster exploit. While all servers must be patched, the ISA Server 2000 firewall provided the lead time administrators needed to evaluate the patch and install it on their Exchange Servers.

 

Secure Remote Access for the OWA Client using SSL Bridging, Delegation of Basic Authentication, Client Certificate Authentication and URLScan

 

Remote users often connect from networks that allow outbound HTTP and SSL connections only. This simplifies the firewall management for the hotel operators, but plays havoc on any remote access email solution based on the full Outlook MAPI client or the more common SMTP/POP3/IMAP4 clients. Fortunately, Outlook Web Access (OWA) provides a substantial subset of the complete set of Exchange features, thus allowing remote users a good email experience.

 

Traditional firewalls pass incoming HTTP and SSL connections from the firewall’s external interface to the OWA server on the internal network. This provides an effective remote access solution but at the cost of an abysmal level of security. More sophisticated firewalls are able to examine limited aspects of the HTTP connection and determine if the connection is valid..

 

The problem is that even these more sophisticated firewalls cannot evaluate the validity of the commands and data in an SSL connection. The information is hidden inside the SSL stream or “tunnel” that is encrypted from end to end between the OWA client and OWA server on the internal network. The only thing the non-ISA Server 2000 firewall can do is pass packets. You have to hope the OWA server is able to evaluate the validity of the messages and protect itself, because the non-ISA Server 2000 firewall isn’t going to help you.

 

ISA Server 2000 firewalls solve this problem by supporting SSL to SSL bridging. The ISA Server 2000 firewall acts as a “bridge” between two separate SSL connections. When these SSL packets “cross the ISA bridge”, the packets are unencrypted and inspected. Packets failing inspection are dropped. Inspection can be performed by a special version of URLScan included with ISA Server 2000 Feature Pack 1. You can also use any one of a large number of third party applications can be installed to further enhance the inspection mechanism.

 

How does SSL to SSL bridging work? First, the OWA client negotiates an SSL link with the external interface of the ISA Server 2000 firewall and sends the connection request through this link. The ISA Server 2000 firewall decrypts the SSL messages and exposes them to its application layer inspection filters. The firewall drops connections that don’t meet validity requirements.

 

If the packets are valid, then the ISA Server firewall creates a second secure SSL link. This time, the SSL link is between the ISA Server 2000 firewall’s internal interface and the OWA server on the internal network. Data transferred between the ISA Server firewall and the OWA server on the internal network are passed through this second SSL link.

 

The OWA server’s responses are passed to the ISA Server firewall’s internal interface through the second link. The ISA Server firewall again decrypts the messages, examines them for validity, and then re-encrypts the valid messages to forward to the remote OWA client via the first SSL link. As you can see, there’s a lot of encryption and decryption going on here!

 

It’s the bridging of the SSL connection that makes ISA Server 2000 firewalls the firewall of choice for organizations allowing remote access to their OWA sites.

 

You can extend the level security provided by SSL to SSL bridging by using the delegation of basic credentials feature provided by ISA Server 2000 Feature Pack 1. You don’t need to worry about using basic authentication because the SSL link protects credentials from being intercepted. Traditional firewalls pass authentication requests from the OWA client to the OWA server and allow a direct, uninspected, unevaluated and unauthenticated communication link between an OWA client and OWA server. There’s a very high chance that an unauthenticated host is an attacker.

 

ISA Server 2000 firewall’s protect secure the OWA server against this problem by requiring the OWA client to authenticate with the firewall. The firewall acts on behalf of the OWA client and forwards the user credentials to the OWA server. Only after the user is successfully authenticated does the ISA Server 2000 firewall allow anything to pass from the OWA client and OWA server.

 

The ISA Server 2000 firewall can go even farther to protect your OWA site by requiring dual factor authentication. A user name and password represents one factor. You can require the OWA client to present a user certificate to the firewall before a user name and password are accepted. The certificate authentication is the second factor in a dual factor authentication scheme. You can further enhance dual factor authentication by using certificates on smart cards and biometric solutions.

 

Secure Remote Access for the Full Outlook 2003 MAPI Client using RPC over HTTP

 

OWA provides a significant improvement over SMTP/POP3/IMAP4 client access, but it still suffers from providing a only a subset of the full Outlook MAPI client’s features. Another issue with OWA is that the interface doesn’t look that same as the full Outlook MAPI client interface. This can be disconcerting for remote users and reduce their overall level of productivity. An ideal solution is to provide the firewall-friendliness provided by OWA and the full, feature-rich email and collaboration experience provided by the full Outlook MAPI client.

 

The ideal solution is now available in the form of secure RPC over HTTP connectivity. If you have Outlook 2003 and Exchange Server 2003, you can use the RPC over HTTP protocol to allow remote Outlook MAPI client access to the Exchange Server. RPC messages are contained in the HTTP communication. An RPC over HTTP proxy unwraps the messages to expose the RPC commands and then forwards them to the Exchange Server.

 

ISA Server 2000 secures the RPC over HTTP connections in the same way that it secures OWA connections: SSL to SSL bridging, delegation of basic credentials and URLScan. The connection between the Outlook 2003 client and the external interface is secured by SSL. The connection between the internal interface of the ISA Server 2000 firewall and the RPC over HTTP proxy on the internal network is secured by SSL. The ISA Server 2000 firewall examines the HTTP messages moving between the Outlook 2003 client and RPC over HTTP proxy server on the internal network and drops invalid HTTP connections.

 

You can further enhance the security of the RPC over HTTP solution by encrypting the connection between the RPC over HTTP proxy server (which is an IIS 6.0 server running the RPC over HTTP service) and the back end Exchange Servers. No third party software is required. You can IPSec transport mode security, which is built-in into Windows 2000 and Windows Server 2003.

 

Outlook 2003 RPC over HTTP provides a nice blend of security and accessibility. All links between the Outlook 2003 client and Exchange Server are encrypted. The only limitation is that the secure RPC filter does not inspect the RPC over HTTP connection. The RPC filter prevents RPC exploits from reaching the Exchange Server. Connections made over a RPC over HTTP link are not exposed to the RPC filter and represent a theoretical risk. However, there are no known RPC exploits at this time

 

Smart POP3 and SMTP and Application Filters

 

ISA Server 2000 firewalls are equipped to handle older email protocols in a secure fashion. Some organizations prefer to use low footprint email applications that support traditional, lower functionality email protocols such as SMTP, POP3 and IMAP, for their remote users. The ISA Server 2000 firewall is able to forward connection requests from these older email clients to the mail services on the Exchange Server.

 

However, the ISA Server 2000 firewall does not let the SMTP and POP3 connections through to the Exchange Server without validating them. With the help of smart POP3 and SMTP filters, the ISA Server 2000 firewall inspects and evaluates the connection requests from remote users. If a remote host attempts a buffer overflow attack, the firewall stops the attacker in his tracks and denies the request.

 

The SMTP Message Screener Protects from Spam and Dangerous Attachments

 

Unsolicited email messages for commercial and other interests represent a major portion of Internet traffic. These “spam” messages can put your organization at risk due to either the content of the message subject or body, or to dangerous attachments bound to the spam message. In addition, dangerous attachments can be distributed by means other than spam, such as Internet worms that automatically search infected user’s email client application for addresses and automatically send messages to people contained in the infected users address list.

 

ISA Server 2000 includes the SMTP Message Screener that can be used in conjunction with the SMTP filter to prevent malicious and unwanted email content from reaching your users mailboxes. The SMTP Message Screener can filtering email using a number of different methods:

 

The SMTP Message Screener allows you to block inbound messages based on the source user address. If you have identified a user or group of user email accounts that you do not want to receive email from, you can enter those accounts into the SMTP Message Screeners block list. If you have identified entire email domains from which you do not wish to receive mail, you can enter those domains into the SMTP Message Screener’s block list.

 

Perhaps the greatest dangerous of SMTP mail messages is their ability to carry attachments of virtually any file type. Email attachments can carry worms, viruses and other email exploits. Attachments can be dangerous even when not carrying an exploit, such as when the attachment contains a document containing proprietary corporate information. The ISA Server 2000 SMTP Message Screener allows you to block attachments based on their file extension (for example, you can block all .exe files), by the file name (for example, you may not want to block all .exe files, just the file name exploit.exe) or by attachment size (you may want to block all attachments more than 1 MB in size).

 

The SMTP Message Screener can examine the content of the email message and block messages containing offensive or otherwise undesirable content. You can block messages that contain keywords in either the message subject line or the body of the message.

 

For each blocked message you have the option to:

 

You can hold the block messages in the BADMAIL folder on the machine running the SMTP message screener. You can then review the messages in the folder at a later time to see the content of the messages and determine the effectiveness of your message blocking polcies.

 

Blocked messages can be forwarded to an email address for later viewing. You may want to create a special account for the email security administrator and have the security administrator review the messages in this account for a hardened machine. The hardened machine protects the rest of the network from any adverse effects that may take place when the email administrator views a message with a potential exploit.

 

The SMTP Message Screener can immediately delete Spam and other unwanted mail. If you have great faith in the nature of your keywords, blocked domains or attachment rules, then you may wish to immediately delete the unwanted messages to save disk space on the SMTP Message Screener machine or on the Exchange Server containing the email security administrator’s account.

 

The SMTP Message Screener can be installed on the ISA Server firewall itself, on an independent SMTP relay computer between the ISA Server firewall and the Exchange Server, or on the Exchange Server computer. The SMTP Message Screener can also examine outbound email messages. Filtering outbound messages protects other organizations from receiving worms and other malicious content from machines located in your organization by blocking these messages before they ever leave your network.

 

Summary

 

Remote access to corporate email requires a firewall that can secure the connection between the mail client and the Exchange Server. In addition, the user experience should not be degraded because of limitations in the firewall technology that allows inbound connections to the Exchange Server. ISA Server 2000 firewalls provide a high level of security by leveraging SSL to SSL bridging, basic authentication, forced encryption for MAPI client connections, HTTP protocol inspection, and RPC over HTTP. The intelligent layer 7 aware ISA Server 2000 firewall allows remote users the best possible email experience with a higher level of security for the connection than any other firewall in its class. It just doesn’t get much better than that!