Apache Security - Ivan Ristic [134]
Scalability and availability improvements
High security networks are likely to host mission-critical systems. Such systems often have specific scalability and availability requirements. (In Section 9.5.2, I discuss some of the approaches as to how these requirements can be accommodated.)
Reverse Proxy Patterns
So far I have discussed the mechanics of reverse proxy operation. I am now going to describe usage patterns to illustrate how and why you might use the various types of reverse proxies on your network. Reverse proxies are among the most useful tools in HTTP network design. None of their benefits are HTTP-specific—it is just that HTTP is what we are interested in. Other protocols benefit from the same patterns I am about to describe.
The nature of patterns is to isolate one way of doing things. In real life, you may have all four patterns discussed below combined onto the same physical server.
For additional coverage of this topic, consider the following resources:
"Reverse Proxy Patterns" by Peter Sommerlad (http://www.modsecurity.org/archive/ReverseProxy-book-1.pdf)
"Perimeter Defense-in-Depth: Using Reverse Proxies and other tools to protect our internal assets" by Lynda L. Morrison (http://www.sans.org/rr/papers/35/249.pdf)
Front door
The front door reverse proxy pattern should be used when there is a need to implement a centralized access policy. Instead of allowing external users to access web servers directly, they are directed through a proxy. The front-door pattern is illustrated in Figure 9-2.
Figure 9-2. Front door reverse proxy
This pattern has two benefits:
Single point to enforce access policy
Centralized logging
The front door reverse pattern is most useful in loose environments; for example, those of software development companies where developers have control over development servers. Allowing clients to access the applications as they are being developed is often necessary. Firewalls often do not offer enough granularity for giving privileges, and having an unknown number of servers running on a network is very bad for security.
Integration reverse proxy
The configuration of an integration reverse proxy, illustrated in Figure 9-3, is similar to that of a front door pattern, but the purpose is completely different. The purpose of the integration reverse proxy is to integrate multiple application parts (often on different servers) into one unique application space. There are many reasons for doing this:
Single Sign On (SSO).
Increased configuration flexibility (changes can be made to the system without affecting its operation).
Decoupling of application modules; this is possible due to the introduced abstraction.
Improved scalability and availability. For example, it is easy to replace a faulty system.
Figure 9-3. Integration reverse proxy
Basically, this pattern allows a messy configuration that no one wants to touch to be transformed into a well-organized, secured, and easy-to-maintain system.
There are two ways to use this pattern. The obvious way is to hide the internal workings of a system and present clients with a single server. But there is also a great benefit of having a special internal integration proxy to sort out the mess inside.
In recent years there has been a lot of talk about web services. Systems are increasingly using port 80 and the HTTP protocol for internal communication as a new implementation of remote procedure calling (RPC). Technologies such as REST, XML-RPC, and SOAP (given in the ascending level of complexity) belong to this category.
Allowing internal systems to communicate directly results in a system where interaction is not controlled, logged, or monitored. The integration reverse proxy pattern brings order.
Protection reverse proxy
A protection reverse proxy, illustrated in Figure 9-4, greatly enhances the security of a system:
Internal servers are no longer exposed to the outside world. The pattern introduces another layer of protection for vulnerable web servers