Apache Security - Ivan Ristic [135]
Network topology remains hidden from the outside world.
Internal servers can be moved out of the demilitarized zone.
Vulnerable applications can be protected by putting an HTTP firewall on the reverse proxy.
Figure 9-4. Protection reverse proxy
The protection reverse proxy is useful when you must maintain an insecure, proprietary, or legacy system. Direct exposure to the outside world could lead to a compromise, but putting such systems behind a reverse proxy would extend their lifetime and allow secure operation. A protection reverse proxy can also actually be useful for all types of web applications since they can benefit from having an HTTP firewall in place, combined with full traffic logging for auditing purposes.
Performance reverse proxy
Finally, you have a good reason to introduce a reverse proxy to increase overall system performance. With little effort and no changes to the actual web server, a reverse proxy can be added to perform the following operations (as seen in Figure 9-5):
SSL termination, such that SSL communication is terminated at the proxy and the traffic continues unencrypted to the web server
Caching
Compression
Figure 9-5. Performance reverse proxy
Moving these operations to the separate server frees the resources on the web server to process requests. Moreover, the web server (or the application) may not be able to support these operations. Because the reverse proxy operates on the HTTP level, the additional functionality can be introduced in front of a web server of any type.
Advanced Architectures
There are three reasons why you would concern yourself with advanced HTTP architectures:
You want to achieve higher availability. Having a system down while the server is being repaired is unacceptable.
The number of users is likely to be greater than one server can support, or is likely to grow (so you desire scalability).
That cool security reverse proxy you put in place centralizes HTTP requests, and you have to deal with the resulting bottleneck in the system.
It would be beneficial to define relevant terms first (this is where Wikipedia, http://www.wikipedia.org, becomes useful):
Scalability
The ability of a system to maintain performance under increased load by adding new resources (e.g., hardware).
Availability
The percent of the time a system is functioning properly during a given time period.
Fault tolerance
The ability of a system to continue to function in spite of failure of its components.
High availability
The ability of a system to function continuously, achieving high availability rates (e.g., 99.999%).
Load balancing
The distribution of the system load across several components, in order to utilize all available resources.
Failover
A backup operation that automatically changes the system to reroute its operation around a faulty component.
Mirroring
The creation of a redundant copy of a component, which can replace the original component in case of a failure. A redundant copy in a mirrored system is often working in stand-by; it starts operating only after a failure in the mirrored component occurs. If both components operate simultaneously, the term cluster is more appropriate.
Clustering
A configuration of components that makes them appear as a single component from the outside. Clusters are built to increase availability and scalability by introducing fault tolerance and load balancing.
We will cover the advanced architectures as a journey from a single-server system to a scalable and highly available system. The application part of the system should be considered during the network design phase. There are too many application-dependent issues to leave them out of this phase. Consult the following for more information about application issues related to scalability and availability:
"Scalable Internet Architectures" by George Schlossnagle and Theo Schlossnagle (http://www.omniti.com/~george/talks/LV736.ppt)
"Inside LiveJournal's Backend" by Brad Fitzpatrick (http://www.danga.com/words/2004_mysqlcon/)