Reverse-Proxy Systems in the DMZ

Reverse-Proxy Systems in the DMZ

One of the most cost-effective and secure methods of providing access to critical systems is through a reverse-proxy. Proxy simply means to "act on behalf of another entity." People typically think of proxy as a forward-proxy, which is done through firewalls using NAT, web caches, or web proxies, from internal users to the Internet. A proxy typically has a many-to-one relationship, such as a firewall with NAT, mapping many internal users with private addresses to a single globally routed address outside the firewall. An example of a simple many-to-one web-based proxy is shown in Figure 6-8. The proxy may be used to provide a centralized mechanism for web content filtering, web content caching, or user authentication.

image from book
Figure 6-8: A simple example of a forward-proxy

The concept of a reverse-proxy is the same as a forward-proxy, but think of traffic flowing in the reverse direction (Figure 6-9), from the Internet in to secure systems in your network. Let us assume that you wish to provide the following applications to your corporate users from any location on the Internet, through a reverse-proxy:

  • Electronic mail

  • Corporate file shares

  • Corporate address book and/or calendars

  • Customer Relationship Management (CRM) database

image from book
Figure 6-9: A simple example of a reverse-proxy

You can probably imagine that each of these applications may provide access to confidential and/or proprietary information, and each may run on a different platform. In addition, each application may have different authentication mechanisms. However, one thing each of these applications probably has in common is a web-based client access mechanism.

Given all of the DMZ designs we described previously, which one appears best suited for deployment of these applications? All but the hierarchical firewall design seem to have risks that obviate their use for these applications. However, with the use of a reverse-proxy system, even the traditional DMZ deployment can be made secure for these applications.

Note 

We are assuming that each application has a web-based client access mechanism. However, many applications today will function through a web-based reverse-proxy, even if they do not contain web-based, client access middleware such as Java.

There are a variety of examples we could present for a reverse-proxy in the DMZ. Instead, we present a real case study from a current customer of ours.

Reverse-Proxy Case Study

Problem: A small company of approximately 250 employees repairs and maintains heavy construction equipment. The company has field service trucks that travel to remote construction and mining sites to repair heavy equipment. The drivers rarely visit the corporate offices, so they need secure Internet access to check parts inventory at the corporate office, send and receive e-mail, access corporate file shares to view operator manuals, enter work-time in the time-keeping database, and obtain anti-virus updates. The work sites are typically so remote that even cell phone access is unavailable, so the company implemented a satellite communication system. The satellite network provider interconnected with Internet service providers, which provided the field trucks with Internet access. The company attempted to use IPSec VPN access over the satellite system, but the delay imposed by the long round-trip of packets over satellite rendered IPSec unusable.

The company had the following requirements for its system:

  • It must perform well over a satellite communication network.

  • All communication between field trucks and the corporate network must be encrypted.

  • It must support Microsoft Outlook Web Access (OWA).

  • It must support Microsoft file sharing.

  • It must support Microsoft NTLM authentication and cached credentials.

  • It must support anti-virus signature definition updates.

  • It must support terminal emulation for an interactive, command-line parts inventory database on an IBM AIX system.

Solution: We proposed a reverse-proxy system deployed behind the corporate firewall. The reverse-proxy was a hardened Linux system running an Apache web server with SSL and digital certificate-based authentication. The Apache server also included a module for pass-through NTLM authentication to Active Directory. Users would connect to the reverse-proxy, authenticate, then the reverse-proxy presented users with a menu of internal systems to access, including OWA, file shares (through WebDAV), the time-keeping system, and the parts inventory system.

While NTLM authentication functioned transparently with the time-keeping system and the parts inventory system, the pass-through authentication did not function with OWA or WebDAV file shares, since these applications already utilize NTLM authentication. In this case, the reverse-proxy did not authenticate the user, but simply passed the user's request to the appropriate system, and authentication was performed from the end system to Active Directory. Terminal emulation for the parts inventory database was accomplished through a vendor-supplied Java client, which was "tunneled" through the SSL connection to the end users.

Given some of the budget and technical requirements of the customer, we had to customize some aspects of this design. The following caveats applied to this design:

  • Microsoft Internet Explorer is the only browser supported, due to the requirement for NTLM authentication and cached credentials.

  • The reverse-proxy was placed inside the firewall because the time-keeping system did not support HTTPS connections. The end-user connection to the proxy was encrypted with SSL (over the Internet), but the reverse-proxy communication was unencrypted to the time-keeping system.

  • The browsers had to be configured with Integrated Windows Authentication to use NTLM with the reverse-proxy. In addition, browsers had to have trusted security zones enabled, with host names for all internal systems to be accessed.

  • Since the reverse-proxy is behind the firewall and only a single globally routed IP address is "visible," the remote workstations had to be configured with specific host names for each internal server (application), which mapped to the single IP address.

  • The reverse-proxy was configured with the <VirtualHost> tag, which maps the client's requested host to the internal IP address of the server behind the proxy.

This is just one example of a design for a reverse-proxy system but it fit the specific requirements perfectly for this customer. The table below enumerates some of the risks and benefits.

Risks

Benefits

Policy management is more complex, and human error may lead to unintended attack or intrusion.

More granular filtering and policy enforcement between security zones.

Capital and operating expense may be prohibitive due to additional systems to manage and complexity of policy enforcement.

Strict policy enforcement between zones helps isolate intrusion to a specific zone.

 

Denial-of-service attacks are more difficult to sustain.



Extreme Exploits. Advanced Defenses Against Hardcore Hacks
Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)
ISBN: 0072259558
EAN: 2147483647
Year: 2005
Pages: 120

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net