Security

SolutionBase: Understand how ISA Server 2004's firewall can help secure Exchange Web services

If you're using Outlook Web Access to allow remote users to access your Exchange server, you don't want to expose your network to outside attack at the same time. Here's what you need to know about how ISA Server 2004's firewall may help.

ISA Server 2004 (ISA firewall) is network firewall that provides protection against both internal and external network threats using multiple technologies. The ISA firewall combines sophisticated stateful packet and application layer inspection with high performance circuit filtering to provide an exceptional level of security for both Microsoft and non-Microsoft networks. Ever since the release of ISA Server 2000, the ISA firewall brand of firewalls have been the thought leaders in application layer inspection protection for your network servers and services.

In this article I'll explain some of the concepts behind the ISA firewall's secure remote access solution to Exchange Server Web services and then in part 2 of the series I'll go through the details of the configuration I used to demonstrate how the HTTP security filter works to protect Exchange Server Web services.

Why would I want to use ISA to begin with?

One of the most compelling reasons for bringing an ISA firewall into your network is when you want to provide secure remote access to your Microsoft Exchange Servers. Microsoft Exchange includes a number of Web and non-Web based technologies that you can make available to home workers, road warriors and partners. These include:

  • Outlook Web Access (OWA)
  • Outlook Mobile Access (OMA)
  • Exchange ActiveSync
  • Secure Exchange MAPI/RPC
  • Outlook RPC/HTTP
  • SMTP
  • POP3 and secure POP3S
  • IMAP4 and secure IMAP4S

The ISA firewall provides a number of features that enable you to provide a high level of security and accountability for remote access to Exchange Servers using one or more of the following ISA firewall technologies:

  • SSL to SSL bridging
  • HTTP inspection with the HTTP security filter
  • URL inspection and normalization
  • OWA forms-based authentication
  • SMTP Message Screener
  • SMTP buffer overflow filter
  • POP3 buffer overflow filter
  • Pre-authentication for inbound connection requests

How SSL bridging works

One of the cornerstone technologies that enables the ISA firewall to provide a superior level of protection against attacks from external users is its SSL to SSL bridging feature. SSL to SSL bridging allows the external client to establish a secure SSL connection to the external interface of the ISA firewall. The ISA firewall then decrypts the sessions and statefully inspects the HTTP communications using the HTTP security filter. If the communications do not represent a potential threat, then the ISA firewall re-encrypts the HTTP session and forwards the connection to the Exchange Web services server on the corporate network.

Figure A

How the ISA firewall implements SSL to SSL bridging

Figure A shows the request/response path for SSL to SSL bridging connections from an external client to an Exchange Server on the corporate network. The series of events proceed as described in the following steps:

  1. The OWA client sends the request https://www.internal.net/exchange/ to the external interface of the ISA firewall publishing the OWA Web site
  2. The ISA Server firewall checks its Web Publishing Rules to see if it has a Web Publishing Rule that is configured to accept incoming connects to the FQDN www.internal.net and the path /exchange If there is a Web Publishing Rule matching this FQDN and path, then the communications are handled based on the forwarding instructions included in the Web publishing rule. However, before the ISA firewall's Web Proxy and HTTP security filters have the opportunity to evaluate the URL, the SSL session must be established. In order to accomplish this, the ISA firewall must impersonate the OWA site on the corporate network. This impersonation takes place by having the ISA firewall present a certificate with the name of the Web site on it. The common/subject name on the certificate the ISA firewall uses to impersonate the OWA Web site must be the same as the FQDN used by the external OWA client to connect to the site. In this example, the common name on the certificate the ISA firewall uses to impersonate the OWA Web site must be www.internal.net so that it matches the FQDN the external OWA client uses to access the OWA Web site.
  3. The ISA firewall decrypts the packets, performs application layer inspection using its HTTP security filter, and then creates a new SSL connection between itself and the internal OWA Web site. Just like when the external OWA client connects to the external interface of the ISA firewall, the ISA firewall's Web Proxy filter acts as a client to the OWA Web site on the internal network. The request the Web Proxy filter sends to the OWA site on the internal network must match the common/subject name on the certificate on the OWA Web site. That is why we must configure the request to be forwarded to www.internal.net when we configure the Web Publishing Rule. I'll remind you of this important fact when we discuss the configuration of the Web Publishing Rule in the demonstration configuration section.
  4. The HTTP communications are forwarded to the Web site after the SSL session is established between the ISA firewall and the OWA Web server on the internal network.

Note: All machines participating in this connection (the OWA client, the ISA Server firewall, the OWA Web site) must have the CA certificate of the Certificate Authority that issued the certificate in its Trusted Root Certification Authorities certificate store.

The connection breaks if the common/subject name on the server certificate doesn't match the name used by the client request. There are two places where the connection could break in the scenario above:

  • If the common/subject name on the certificate used by the ISA firewall to impersonate the OWA site doesn't match the server name (FQDN) used by the OWA client on the Internet
  • If the common/subject name on the certificate bound to the OWA Web site doesn't match the server name (FQDN) used by the Web Proxy service to forward the request to the OWA 2003 Web site on the internal network; the name in the request is determined by how you configure the Web Publishing Rule. We will cover this issue in detail in the next article in this series

Contrast how the ISA firewall provides remote access to Exchange Web services to how the conventional "hardware" firewall handles incoming SSL connections to the OWA site. Hardware firewalls are unable to act as the SSL termination point for the external user, so the only thing the hardware firewall can do is check to see if the request was made to the correct IP address and port number (which is TCP port 443 by default for SSL connections).

If the IP address and port number is correct, then the hardware firewall passes the encrypted SSL connection to the OWA site. Attackers, viruses and worms can easily sneak by the hardware firewall by hiding within the SSL tunnel because the hardware firewall is blissfully unaware of the dangers it allows to reach your Exchange Web services sites.

In contrast to the hardware firewall's reckless approach to Exchange Web site security, the ISA firewall can stop the attacks that would otherwise be completely hidden from the hardware firewall. The combination of the HTTP security filter, ISA firewall pre-authentication (discussed next) and SSL bridging makes an ISA firewall sine qua non for any remote access to Exchange Server service design plan.

How ISA OWA forms-based authentication works

Remote users present a different and more problematic set of security risks to your Exchange Server's Web services compared to corporate network clients. On the corporate network, you usually have a great deal of control over the software security configuration on the managed desktop and ideally, laptop clients. You can use Group Policy Objects, security templates, and a wide array of third party offerings on your managed clients to lock down host security so that managed clients present a relatively low security risk to your Exchange Server.

The same can't always be said for users connecting from external locations. Remote users connect from a more heterogeneous set of network devices, including but not limited to:

  • Home computers shared with the rest of the family, including hacker wannabe teenagers and other users who are not security aware, that leads to the home computer being a veritable haven for worms, viruses and trojans
  • Laptop computers owned by the employees that are not part of the corporate managed computer environment
  • Internet kiosks, such as those at airports, enable users Internet access and use a Web browser to connect to Web sites, including your corporate Exchange Server services Web sites
  • Handheld devices, such as PDAs and smart phones
  • Corporate computers owned by friends, colleagues and business partners

One thing that these remote users have in common is that they are connecting from computers and networks of which you have no administrative control. You have no idea what level of security, if any, has been applied to any of the networks the connecting device is currently, or has historically, been connected to.

When you combine the fact that unmanaged computers are more likely to be not up to date on security fixes with the fact that they are often connected to poorly secured networks, it becomes clear that connections from remote hosts present a higher security risk and measures must be taken to mitigate those risks.

One way you can do this is to use ISA OWA forms-based authentication (FBA) at the ISA firewall. The ISA FBA feature enables the ISA firewall to generate the log on form. This has several security advantages over allowing the Exchange Server to generate the log on form:

  • You must allow unauthenticated connections to the Exchange Server in order for the external machine to access the log on form. Internet attackers can leverage these unauthenticated connections to launch an attack against the Exchange Server.
  • When the ISA firewall generates the form, no communicates to the Exchange Server are required to generate the form; the ISA firewall generates the form and sends it to the user.
  • The ISA firewall can pre-authenticate users before allowing any communications back to the Exchange Server. The user must first successfully authenticate with the ISA firewall before any connections are forwarded to the Exchange Server.
  • The ISA firewall allows you to take an additional step in securing the Exchange Server by requiring that the user not only authenticates, but is authorized to connect to the Exchange Server. This prevents users who have no need for remote access from leveraging their valid network credentials to connect to the Exchange Server from potentially dangerous remote locations.
  • The authorized user receives a cookie from the ISA firewall after successfully authenticating. This cookie is used to control session variables. Some of the session variables you can control include blocking attachments based on the user's location, shutting down connections after a predefined idle time based on the user's location, and automatically logging the user off from the Exchange Server if he moves away from the OWA page and goes to another Web site.

OWA forms based authentication is just one of the authentication methods you can use when connecting to the corporate OWA site through the ISA firewall. However, this is the recommended and more secure configuration and there's almost never a compelling reason not to use the ISA firewall's FBA feature.

Figure B shows the configuration interface for the ISA FBA authentication mechanism. Later in this article series when we get to the point of reconstructing the demo, we'll create a Web Publishing Rule that publishes the OWA site to remote users using the ISA FBA.

Figure B

The OWA forms-based authentication dialog box

You have the following options on the OWA Forms-based Authentication page:

  • Idle session timeout: Clients on public machines Use this option to control idle session timeout value for users connecting from a public access machine. This value should be relatively short, as users may walk away from these machines and still be logged into the OWA site. A subsequent user can then "shoulder surf" into the previous user's mailbox and potentially obtain useful information about the user, or the corporation. The default value is 22 minutes, which I find to be rather long. You might want to start this value at 5 minutes and then lengthen it only if you find that it's not workable in your organization.
  • Idle session timeout: Clients on private machines Use this option to control the idle session timeout for users who are working at private machines. These are typically machines that the user owns, such as a home office computer or a laptop. These are not public machines because the general public doesn't have access to these machines. However, these machines are not corporate managed devices either, and thus are unlikely to meet corporate data security requirements. The default value is 36 hours, which seems extraordinarily long. Try a value of 1 hour and lengthen it only if users in your organization find this unworkable.
  • E-mail Attachments: Block e-mail attachments on public machines Use this option to prevent users at public machines from accessing e-mail attachments.
  • E-mail attachments: Block e-mail attachments on private machines Use this option to prevent users at private machines from accessing email attachments.
  • Log off OWA when the user leaves OWA site Use this option to automatically log the user off the OWA site when they leave the OWA mailbox page. When a user is at the OWA page and then clicks a link to go to another site, the user will normally be still logged into his mailbox. If another user comes in after this user and looks at the URL history in the Address bar, that subsequent user can easily select that URL and be automatically entered into the user's mailbox. When you select the Log off OWA when the user leaves OWA site option, the user will be logged off when he leaves the OWA web page and no subsequent user will be able to access the mailbox using that user's establish credentials.

How the RPC over HTTP protocol works and how the ISA firewall secures the traffic

The ISA firewall's stateful application layer inspection feature set can also help secure connections from Outlook 2003 clients that are able to use the RPC over HTTP protocol to connect to the Exchange Server via an RPC over HTTP proxy. This enables the external Outlook 2003 client to access the Exchange Server even when the client is behind a firewall that only allows outbound HTTP and HTTPS.

The RPC/HTTP protocol enables the Outlook 2003 client to encapsulate or wrap native Outlook RPC MAPI communications in a secure HTTP header (SSL) and tunnel the Outlook MAPI RPC communications in a SSL tunnel. While this method does add a significant level of protocol overhead and slows down connections to the Exchange Server, this negative performance effect can be mitigated to a certain extent by using the Outlook 2003/Exchange 2003 cached Exchange mode configuration.

The RPC/HTTP protocol is actually a form off SSL VPN. There are four general categories of SSL VPNs, and the RPC/HTTP protocol matches the SSL VPN approach which is known as protocol tunneling. Protocol tunneling enables client/server communications to take place via a protocol tunneling proxy. The proxy device removes the tunneling protocol header over which the native protocol is encapsulated, and then forwards the unwrapped native protocol to the appropriate application server.

This solves two major problems for the native Outlook MAPI client communications over the Internet:

  • Even though both ISA Server 2000 and ISA 2004 include a secure Exchange RPC filter that enables secure native Outlook/Exchange RPC communications over the Internet, the outbreak of the Blaster worm effectively made the overwhelming convenience and security provided by the secure Exchange RPC filter moot. The reason for this is that many major ISPs blocked outbound connections to TCP port 135, which is the RPC endpoint mapper port that the ISA firewall's secure Exchange RPC filter listens for incoming communications. Since Blaster struck, using secure Exchange RPC over the Internet has become a hit or miss situation.
  • Many locations are now restricting outbound access to only HTTP and HTTPS. The reasons for this are not entirely clear, but it can't be denied that this is the prevailing approach to network management for many companies. This is most commonly a problem in conference centers and smaller businesses. Most hotels at this time enable more liberal protocol access through their firewalls and routers. In order to circumvent these restrictions, Microsoft developed the RPC/HTTP protocol solution so that users could still use the native Outlook MAPI client to connect to Exchange 2003 Servers. Unfortunately, RPC/HTTP only works with Outlook 2003 and Exchange 2003 combinations. If you have earlier versions of the client or server, then you will not have access to this solution.

Figure C shows the request/response path for RPC/HTTP communications.

Figure C

The request/response path for RPC/HTTP communications

The following explains the response/response path communications between the Outlook 2003 RPC/HTTP client and the Exchange 2003 Server:

  1. The external Outlook 2003 client encapsulates the Outlook MAPI RPC communications in a secure HTTP header (SSL) and sends the SSL connection request to the ISA firewall.
  2. The ISA firewall accepts the incoming RPC/HTTP connection request and decrypts the communication. The ISA firewall then performs HTTP application layer inspection using its HTTP security filter. If the HTTP portion of the communication does not pass the screening criteria set forth in the HTTP security filter, then the connection attempt is dropped and no connections are forwarded to the RPC/HTTP proxy on the corporate network.
  3. If the communications pass screening by the HTTP security filter, then the ISA firewall establishes a second SSL tunnel, this time between itself and the RPC proxy and re-encrypts the communications.
  4. The RPC/HTTP proxy server decrypts the communications, removes the HTTP header, and forwards the native Outlook/Exchange RPC protocol communications to the appropriate Exchange Server.
  5. The Exchange Server uses the native Outlook/Exchange RPC protocol to send it's responses to the RPC/HTTP proxy. The RPC/HTTP proxy encapsulates the RPC communications in an HTTP header, re-encrypts them using SSL and returns the response to the ISA firewall.
  6. The ISA firewall decrypts the communications from the RPC/HTTP proxy, uses the HTTP security filter to inspect the responses and drops the connection if the response does not meet the requirements of the RPC/HTTP filter. If the response passes inspection, then it is re-encrypted and returned to the Outlook 2003 client.

The ISA firewall also improves security for RPC/HTTP communications by requiring authentication at the ISA firewall before allowing the RPC/HTTP communications to the RPC proxy server. This is often referred to as ISA firewall pre-authentication.

This is vital security because the RPC/HTTP protocol requires that the RPC/HTTP proxy server be a domain member computer. You never want to allow anonymous connections directly to a domain member computer that isn't a firewall (such as a Check Point server or an ISA firewall) because an anonymous user can leverage this communication to attack the RPC/HTTP proxy. The ISA firewall can force pre-authentication at the firewall and drops all connections from users who cannot successfully authenticated and those who do successfully authenticated, but who are not authorized to use RPC/HTTP to connect to the corporate Exchange Server.

Issues in publishing both OWA/FBA and OMA/ActiveSync sites using a single IP address

Most organizations that choose to bring an ISA firewall in to protect Exchange Servers want to make all the Exchange Server Web services available to their users. This includes OWA, OMA and Exchange ActiveSync. Allowing connections to all three of these services supports remote access connections from desktop computers, laptop computers, kiosks, and handheld devices such as PDAs and smart phones.

This introduces a problem for organizations that have only a single IP address bound to the external interface of the ISA firewall. When ISA FBA is enabled for a Web Publishing Rule, the Web listener used by the Web Publishing Rule to accept the incoming connections for the rule is configured to use ISA FBA as its authentication protocol. Web listeners are configured to listen on a specific IP address. You cannot create two Web listeners using the same IP address.

The problem is that Outlook 2003 and handheld devices do not know what to do with the log on form when the ISA firewall presents it to them. So, if FBA is enabled on the Web listener used to publish the RPC/HTTP proxy and the OMA and ActiveSync sites, the connection attempts will fail.

The solution to the problem is to create a second Web listener that uses only Basic authentication and that listens on a second IP address bound to the external interface of the ISA firewall. Of course, the second IP address solution is not much help for organizations that only have a single public IP address and lack the option to obtain additional addresses. In this case, there are at least three potential solutions:

  • Use an ISA firewall add-on application. There is an excellent ISA firewall add-on created by Collective Software (www.collectivesoftware.com) named FlexAuth. The FlexAuth application is able to detect the User-Agent header in the HTTP request and then provide the appropriate authentication method based on the application making the connection. If the User-Agent indicates the connection is coming from a PDA or Outlook 2003, then the Web listener switches from ISA FBA to Basic authentication transparently.
  • Use a Web proxy device in front of the ISA firewall, such as another ISA firewall or ISA Server 2000. In this scenario, the front-end Web proxy device has a single IP address bound to its external interface. Two rules are created on the front-end Web proxy: one rule containing the paths used by OWA and the second rule containing the paths used by RPC/HTTP, OMA and Exchange ActiveSync. The front-end Web proxy NATs the connections to the back-end ISA firewall. The back-end ISA firewall has two IP addresses bound to its external interface, which isn't a problem because you can use as many private IP addresses on the external interface as you like. The OWA rule on the front-end Web proxy device forwards connections with the OWA paths to one IP address on the back-end ISA firewall, and the RPC/HTTP, OMA and Exchange ActiveSync rule on the front-end Web proxy device forwards connections requests including the RPC/HTTP, OMA and Exchange ActiveSync path to a second IP address on the external interface of the back-end ISA firewall
  • Use a technique created by Kai Wilke (ISA firewall MVP) that I describe in detail over at http://www.isaserver.org/tutorials/2004pubowamobile.html. This method uses some creative tricks on the ISA firewall's Web listener configuration to make it believe there is a configuration similar to that seen when there is a Web proxy device located in front of the ISA firewall, as I described in the second option. The major disadvantage of using this method is that is not supported by Microsoft and has not been thoroughly regression tested.

If you already have another ISA 2004 firewall or ISA Server 2000 in house, then you can put it to good work by acting as the front-end ISA firewall and Web proxy device. If you don't have a Web proxy device that can act as front-end Web proxy for the ISA firewall, the most cost effective solution is to go with FlexAuth. The no-cost solution is to use the Kai Wilke trick, but it does suffer from the major disadvantages of not being supported by Microsoft and has never been thoroughly regression tested.

More to come

In this, part 1 of a two part article series on how to provide a very high level of remote access protection to Exchange Web services, I discussed several features of the ISA firewall's security toolset that enable the ISA firewall to secure remote access connections to Exchange Server Web services. The ISA firewall's SSL to SSL bridging, ISA firewall FBA, HTTP security filter, and stateful packet inspection firewall core all work together to secure remote access connections to Microsoft Exchange Servers. In part 2 of this series, we'll go into the details of the HTTP security filter and then configure Web Publishing Rules that employ custom HTTP security filter configurations to provide rock solid security for remote access connections to OWA.

Editor's Picks

Free Newsletters, In your Inbox