Apache Security - Ivan Ristic [131]
Improved performance
Transparent caching, content compression, and SSL termination are easy to implement at the reverse proxy level.
Application isolation
With a reverse proxy in place, it becomes possible (and easy) to examine every HTTP request and response. The proxy becomes a sort of umbrella, which can protect vulnerable web applications.
Host and web server isolation
Your internal network may consist of many different web servers, some of which may be legacy systems that cannot be replaced or fixed when broken. Preventing direct contact with the clients allows the system to remain operational and safe.
Hiding of network topology
The more attackers know about the internal network, the easier it is to break in. The topology is often exposed through a carelessly managed DNS. If a network is guarded by a reverse proxy system, the outside world need not know anything about the internal network. Through the use of private DNS servers and private address space, the network topology can be hidden.
There are some disadvantages as well:
Increased complexity
Adding a reverse proxy requires careful thought and increased effort in system maintenance.
Complicated logging
Since systems are not accessed directly any more, the log files they produce will not contain the real client IP addresses. All requests will look like they are coming from the reverse proxy server. Some systems will offer a way around this, and some won't. Thus, special care should be given to logging on the reverse proxy.
Central point of failure
A central point of failure is unacceptable in mission critical systems. To remove it, a high availability (HA) system is needed. Such systems are expensive and increase the network's complexity.
Processing bottleneck
If a proxy is introduced as a security measure, it may become a processing bottleneck. In such cases, the need for increased security must be weighed against the cost of creating a clustered reverse proxy implementation.
Apache Reverse Proxy
The use of Apache 2 is recommended in reverse proxy systems. The new version of the mod_proxy module offers better support for standards and conforms to the HTTP/1.1 specification. The Apache 2 architecture introduces filters, which allow many modules to look at the content (both on the input and the output) simultaneously.
The following modules will be needed:
mod_proxy
mod_proxy_http
For basic proxying functionality
mod_headers
Manipulates request and response headers
mod_rewrite
Manipulates the request URI and performs other tricks
mod_proxy_html
Corrects absolute links in the HTML
mod_deflate
Adds content compression
mod_cache
mod_disk_cache
mod_mem_cache
Add content caching
mod_security
Implements HTTP firewalling
You are unlikely to need mod_proxy_connect, which is needed for forward proxy operation only.
Setting up the reverse proxy
Compile the web server as usual. Whenever the proxy module is used within a server, turn off the forward proxying operation:
# do not work as forward proxy
ProxyRequests Off
Not turning it off is a frequent error that creates an open proxy out of a web server, allowing anyone to go through it to reach any other system the web server can reach. Spammers will want to use it to send spam to the Internet, and attackers will use the open proxy to reach the internal network.
Two directives are needed to activate the proxy:
ProxyPass / http://web.internal.com/
ProxyPassReverse / http://web.internal.com/
The first directive instructs the proxy to forward all requests it receives to the internal server web.internal.com and to forward the responses back to the client. So, when someone types the proxy address in the browser, she will be served the content from the internal web server (web.internal.com) without having to know about it or access it directly.
The same applies to the internal server. It is not aware that all requests are