5.8 OWA firewall access

---

It is reasonably common to encounter a requirement to allow access to mailboxes on Exchange servers through a firewall, perhaps to accommodate the needs of traveling users who wish to connect across the public Internet without a VPN. In one scenario, you have one or more front-end servers placed in the DMZ to accept incoming requests from clients and then relay or proxy them onward to the mailbox servers. Another common scenario is to deploy a proxy server such as Microsoft Internet Security and Acceleration (ISA) server in the DMZ and keep the front-end servers safely behind the firewall. Because ISA includes components specially designed to support secure OWA access, it is the most popular choice for OWA deployments.

The front-end servers authenticate user credentials but do nothing with the traffic, since their purpose is to accept the incoming request and channel it to the appropriate back-end mailbox server. To protect communications, firewalls are in place to control external traffic into the DMZ and from the DMZ to the internal network. To make this all work, you open the ports used by Exchange and other associated components on the internal and external firewalls, limiting the open ports to the smallest possible set in order to reduce the potential for hacker attacks. A full set of ports used by Exchange and other infrastructure components is shown in Appendix C.

In most front-end/back-end scenarios, you use Outlook Web Access as the client, although you can take the same approach with Outlook 2003 when it connects to Exchange over HTTP. Figure 5.24 illustrates the basic layout of the front-end/back-end scenario. This is a very simple example that is suitable for small deployments. It is quick and easy to set up, but the basic configuration is not secure because the front- and back-end servers do not encrypt the HTTP streams. You can certainly use IPSec to protect the interserver traffic, but even so, you still must maintain a large number of open ports on the internal-facing firewall, which attackers could exploit if they manage to penetrate the DMZ.

Figure 5.24: Basic layout of OWA access through a firewall.

Larger deployments, such as those used by Application Solution Providers, often deploy proxy servers in the DMZ to process client connects before they reach the Exchange front-end server. You can deploy software (such as ISA) or hardware-based proxy servers (a network appliance such as those made by Nortel and Cisco) to achieve the major advantage of being able to move the front-end server out of the DMZ to behind the internal firewall. Typically, you couple software-based proxy servers with SSL/TLS accelerator cards to offload some of the encryption activity and increase throughput. Hardware-based proxy servers deliver the best performance but they are far more expensive than software equivalents, so the volume of connections you expect to handle often dictates your choice.

Once the front-end server is in the internal network, you do not have to worry about opening ports in the firewall and therefore have less risk of an attack. In addition, clients can use an end-to-end HTTPS connection over port 443 through the DMZ to the front-end server and so protect all traffic from prying eyes.

The proxy server can provide two variations of protection: tunneling and bridging. With tunneled connections, the proxy server passes communications straight through from client to front-end server, and the front-end server does all the processing to decrypt the HTTPS traffic. With bridging, the proxy server intercepts the proxy server client communications and establishes a new connection between the proxy server and the front-end server. You can continue to protect the new connection with SSL, or you can have the proxy server perform the decryption and pass an HTTP stream to the front-end server and so offload the decryption workload from that server. With no need to decrypt traffic, the front-end server is capable of supporting far more client connections. Another advantage is that when the proxy server intercepts the original client connections, it can inspect the packets, decide whether any are suspicious, and terminate their passage.

The requirements for secure access differ from company to company. If you decide that you need to support browser access back through the public Internet, then it is worth taking the time to investigate all of the potential solutions, since technology moves fast in this area. You should also look at alternatives to support other clients, such as implementing a VPN to allow older versions of Outlook and other clients to connect. Given the widespread availability of public LANs (both wired and wireless) in hotels, airports, and other facilities, having VPN access is a great way for users to be able to work online and connect to all corporate resources instead of just being limited to email.

5.8.1 Securing OWA

Mention of firewalls inevitably leads to a discussion about security and the vulnerability of IIS to hacking exploits. The OWA architecture is firmly rooted in IIS and IE, both products that have a checkered history when it comes to hacker exploits. A large number of buffer overflow bugs afflicted both IIS and IE and at times it seemed that a new exploit was reported weekly, followed by a new patch to be applied to either server or browser. To its credit, Microsoft responds as quickly as possible whenever someone reports a new potential security issue (not all reports turn out to be real issues; some are due to lack of knowledge or misunderstanding about software functionality), but this is not the problem: Companies are concerned that deploying IIS and IE will open up holes for future exploits. Outlook is also open to abuse, as is evident in the large number of virus attacks based on macros and other loopholes experienced in the last few years.

Administrators can mitigate their exposure by including IIS and IE in the list of components regularly reviewed for security within the overall messaging infrastructure. You must review and then apply (as appropriate within your environment) Microsoft's tools for increased security, such as the IIS Lockdown tool for IIS 5.0. Be sure that any tool is fully tested before you deploy it into production, since overzealous protection will stop IIS from serving dynamic content and thus halt OWA. Better yet, you can deploy IIS 6.0 and take advantage of its much improved security model. On the client side, the latest versions of IE are more secure, but that is no reason to fail to check for current browser patches and hot fixes that close off reported problems.

5.8.2 IPSec

If you run a front-end/back-end configuration to support clients such as OWA or IMAP4, you probably use a variation of the classic configuration that places the front-end server in the DMZ and the back-end mailbox servers behind the firewall. Exchange does not support SSL encryption of the traffic flowing between the front- and back-end servers and it is a bad idea to leave the traffic unprotected, just in case a hacker manages to penetrate your external firewall and enter the DMZ. You can certainly use a solution such as Microsoft's own Internet Security and Acceleration (ISA) server to bridge SSL traffic across the firewall, but this complicates the configuration by adding additional components and introduces some extra cost. Of course, if you have other uses for ISA, then you can exploit its existence, but if not, you should look at IPSec as a free way to protect the traffic.

IPSec is a set of transport layer extensions to the basic Internet Protocol that binds the Internet together. Because IPSec operates at the transport layer of the network stack, applications do not have to provide special code to take advantage of its existence. Instead, the applications "see" a communications path that is protected, even if they do not know this (or need to). IPSec includes two protocols that complement each other: the Authentication Header Protocol and the Encapsulating Security Payload (ESP) Protocol. From an Exchange perspective, we are more interested in ESP, because we can use it to encrypt datagrams as they pass between servers. Servers that use IPSec use another component, the Internet Key Exchange (IKE) Protocol, to exchange cryptographic keys and negotiate to discover the type of encryption (algorithm and key length) that the two servers support. Once this is done, the servers establish a secure channel between them and encrypted application data then begins to pass across this channel.

When administrators approach IPSec, they often find that the most complicated part of the implementation is the policies that Windows uses to control IPSec. This is a situation where excessive complexity can easily creep in, especially if security wizards attempt to close down every possible channel. However, there is an easy answer, because Windows includes three IPSec policies that you can use immediately. These policies begin to solve the problem for the majority of implementations, so you should always start with them. The three policies are:

• Client Respond Only: This policy lets target servers (such as the mailbox servers) respond to requests from other servers that want to negotiate a secure channel.

• Server Request Security: This policy instructs servers to always attempt to negotiate a secure channel when connecting to another computer. If the negotiation fails (perhaps because the target server does not support IPSec), communication can continue, but it is not protected.

• Secure Server Require Security: This policy forces the server to require the use of IPSec. Be careful with this policy, because it can stop a server from communicating with all but a limited set of servers, or even none, if you make mistakes.

To apply IPSec, we can use the Client Respond Only policy for the back-end mailbox servers, applying the policy to each server using the IP Security Management MMC console. Make sure that the IPSec Policy Agent service is running before you attempt to do anything with IPSec policies. If the service is not running, you will not be able to apply policies to servers and secure channels will not work. Securing the front-end servers takes a little more work, because you need to use the IP Security Policy wizard to create a policy that states:

• The traffic you want to protect flows through port 80

• The IP addresses of the source (front-end) and target (back-end) servers

• Traffic flows across a LAN and does not use a tunnel

• TCP is the required protocol

These are the basics of the required policy. It is wise to leave IPSec policies to an expert if you have not created and applied one before, or make sure that you read up on the subject and do some serious testing before you go anywhere near a production server. When the policies are in place, use the IPSECMON tool from the Windows Resource Kit to ensure that traffic is flowing as expected by viewing the secure channels that are in place. In addition, check that users can access their mailboxes as normal.

5.8.3 Leaving sensitive files around

Some administrators worry that users might leave sensitive information on a PC after an OWA session. Attachments are the usual worry. When users receive an attachment in a message, they can open it, save it, forward it, or delete it just as they can do with any other client. With other clients, they probably use the same PC all the time, so it does not matter if the file remains on disk; but it may matter if someone else comes along, discovers the file, and opens it to read something that he or she should not see.

In the same way that you are powerless if a user forwards confidential information to someone else by mistake, you cannot do much if a user elects to save a file to disk. All you can hope is that the user knows what he or she is doing and will not do anything stupid. OWA minimizes potential problems by setting an already past expiration date on all files that it creates temporarily when users open attachments for viewing. This means that the browser automatically removes the files (because they are expired) when it closes (Figure 5.25). Behind the scenes, OWA creates a file in the user's Temporary Internet Files folder. If you check the time and date of the message (13:01 on December 12, 2002) against the file's expiration date (12:02 on December 12, 2002), you can see how things work. The bottom line is that the software attempts to mitigate problems as much as it can, but you cannot legislate for user behavior, which is where most security problems originate.

Figure 5.25: OWA expiration dates for attachments.

5.8.4 IE enhanced security

If you connect to OWA with a mailbox on an Exchange 2003 server running on Windows 2003, you may be annoyed to discover that you have to log on before you can access your mailbox (Figure 5.26). By default, Windows 2003 implements enhanced security for IE, meaning that users must provide explicit credentials before they can access secure sites.

Figure 5.26: IE6 enhanced security and OWA logon.

You can stop IE from prompting for credentials in a two-step process. First, you use the Add/Remove Programs applet to remove Internet Explorer Enhanced Security Configuration from the set of Windows components. Second, you add the Exchange server that hosts your mailbox as a trusted site for IE (use Internet Options under the IE Tools option to do this).

---