Using a Reverse Proxy to Protect Web Services

A lot of organizations expose their Client Access servers directly to the Internet. If the server is properly hardened and security updates are applied as needed, this scenario will work. However, many organizations have policies that state that no internal web server can have Internet connections directed to it. These organizations will often try to locate the Client Access server role in the perimeter network, which is not recommended. Other organizations are just concerned with improving security wherever possible.

In the previous section, we talked about preventing direct SMTP access to the Hub Transport role by using an SMTP relay located in the perimeter network. You can employ very similar protection by using a reverse proxy.

Figure 20.10 shows an organization that has implemented a reverse proxy in its perimeter network. A reverse proxy is similar to a regular proxy server. Inbound HTTPS is directed to the reverse proxy server instead of the Client Access server. Depending on the type of reverse proxy server, some additional security steps may be taken. The reverse proxy server then places the HTTP data back on the network (either as HTTP or HTTPS) and sends it on to the Client Access server. The internal firewall is configured so that the HTTPS data will be passed through the internal firewall only if it is sent from the reverse proxy server.

Figure 20.10: Implementing a reverse proxy in the perimeter network

The Client Access server will accept the request, process it, and send the response back to the reverse proxy server. The reverse proxy server then sends the requested data back to the originating client. Depending on the reverse proxy server you are using, you may have some additional security benefits associated with using this solution:

• Improved security for all web services, including Outlook Web Access, ActiveSync, Outlook Anywhere, Autodiscover, Availability, and others

• Validation of URL path and sends to the Client Access server only valid virtual directories

• URLs examined for invalid HTTP requests such as directory traversal attacks or buffer overflow attacks

• Authentication offloaded so that the reverse proxy authenticates the client before ever allowing the client to connect to the Client Access server

• The overhead of SSL offloaded so that the reverse proxy rather than the Client Access server handles SSL encryption and decryption

There are a number of different reverse proxy solutions available that can help you improve the security of your published web applications. Microsoft's ISA Server (www.microsoft.com/isa), Blue Coat SG Appliances (www.bluecoat.com), and Squid Web Proxy (www.squid-cache.org) for Linux are just a few examples.

The example in Figure 20.10 shows one possible configuration that will work with most any reverse proxy solution. However, Microsoft ISA Server can also act as a complete firewall solution. Some organizations deploy ISA Server as their only firewall or they use it as an internal firewall. Figure 20.11 shows a configuration where ISA Server is acting as an internal firewall; in this configuration it can also act as a reverse proxy.

Figure 20.11: Using ISA Server as an internal firewall and reverse proxy

If you are using Microsoft ISA Server, the menus and wizards do not refer to this as a reverse proxy feature but rather mail-server publishing.