Apache Security - Ivan Ristic [133]
ProxyPassReverse / http://192.168.0.1/
# additional mod_proxy_html configuration
# options can be added here if required
Reverse Proxy by Redirecting Network Traffic
Sometimes, when faced with a network that is already up and running, it may be impossible or too difficult to reconfigure the network to introduce a reverse proxy. Under such circumstances you may decide to introduce the reverse proxy through traffic redirection on a network level. This technique is also useful when you are unsure about whether you want to proxy, and you want to see how it works before committing more resources.
The following steps show how a transparent reverse proxy is introduced to a network, assuming the gateway is capable of redirecting traffic:
The web server retains its real IP address. It will be unaware that traffic is not coming to it directly any more.
A reverse proxy is added to the same network segment.
A firewall rule is added to the gateway to redirect the incoming web traffic to the proxy instead of to the web server.
The exact firewall rule depends on the type of gateway. Assuming the web server is at 192.168.1.99 and the reverse proxy is at 192.168.1.100, the following iptables command will transparently redirect all web server traffic through the proxy:
# iptables -t nat -A PREROUTING -d 192.168.1.99 -p tcp --dport 80 \
> -j DNAT --to 192.168.1.100
Network Design
A well-designed network is the basis for all other security efforts. Though we are dealing with Apache security here, our main subject alone is insufficient. Your goal is to implement a switched, modular network where services of different risk are isolated into different network segments.
Figure 9-1 illustrates a classic demilitarized zone (DMZ) network architecture.
Figure 9-1. Classic DMZ architecture
This architecture assumes you have a collection of backend servers to protect and also assumes danger comes from one direction only, which is the Internet. A third zone, DMZ, is created to work as an intermediary between the danger outside and the assets inside.
Ideally, each service should be isolated onto its own server. When circumstances make this impossible (e.g., financial reasons), try not to combine services of different risk levels. For example, combining a public email server with an internal web server is a bad idea. If a service is not meant to be used directly from the outside, moving it to a separate server would allow you to move the service out of the DMZ and into the internal LAN.
For complex installations, it may be justifiable to create classes of users. For example, a typical business system will operate with:
Public users
Partners (extranet)
Internal users (intranet)
With proper planning, each of these user classes can have its own DMZ, and each DMZ will have different privileges with regards to access to the internal LAN. Multiple DMZs allow different classes of users to access the system via different means. To participate in high-risk systems, partners may be required to access the network via a virtual private network (VPN).
To continue to refine the network design, there are four paths from here:
Network hardening
General network-hardening elements can be introduced into the network to make it more secure. They include things such as dedicated firewalls, a central logging server, intrusion detection systems, etc.
Use of a reverse proxy
A reverse proxy, as discussed elsewhere in this chapter, is a versatile tool for managing HTTP networks. It offers many benefits with only slight drawbacks. Reverse proxy patterns will be considered in detail here.
Commercial application gateways
An application gateway is a security-conscious reverse proxy. You can create an application gateway out of freely available components, but it is generally not possible to achieve the same level of features as offered by commercial offerings. In the long run, open source tools may catch up; for the time being, commercial application gateways should be considered as a final protection