Risks associated with Reverse-Proxy
We used to put the Web servers in the DMZ and the Application Servers in the LAN. Now we are discussing the risks and benefits of an architecture with a Reverse-Proxy in the DMZ and the rest of the servers (Web & Application servers) in the LAN. What do you think about this change? What are the risks associated with an architecture based on a Reverse-Proxy?
The benefit of using Reverse-Proxy is that your actual
servers have no direct connection to the Internet as they
do if they are in the DMZ. Clients talk to the Proxy,
which in turn can talk to the real server. In order for
this to work, the proxy server needs a way to pass requests
through the firewall to the real server. This is where
there is some additional risk. What ports do you need to
open on your firewall to make this work? Can those openings
in the firewall be restricted to only proxy-to-server communications?
If not, other applications could make use of the opening created
to attack your LAN.
One way to minimize the risk would be to set up a seperate
segment for your servers behind the firewall. Then the firewall
rules that you need to implement for the reverse-proxy can be
limited to that segment and not affect the rest of the LAN (assuming
you are using a firewall that allows seperate rules for each segment).
This gives you the benfit of reverse-proxy that you are seeking,
without changing the firewall protection for the rest of the LAN.
For more information on this topic, check out these resources:
Ask the Expert: The role and placement of a DMZ on a network
Best Web Links: Firewalls
This was first published in December 2001