Reverse Proxy - should it be a different technology stack?

Question

Got a skeptical question about a reverse proxy setup I'm considering.

I've currently got a pair of load balanced application servers in the DMZ (S1,S2 in figure below). These accept inbound requests from external clients. They also connections to internal network resources (e.g. DB server, message broker)

The DMZ setup is pretty standard: two firewalls -- internal and external facing. The external-facing firewall only allows in external requests to specific server resources on specific ports. The internal-facing firewall only allows the DMZ servers to open specified connections to internal network resources (e.g. DB server, message broker)

Now, I have an architectural proposal stating this setup is insecure. The proposal calls for moving the two DMZ servers into the internal network. In the DMZ, they will be replaced by a 'Reverse Proxy' server ('RP' in figure below). The 'RP' will accept inbound requests and proxy them to the S1/S2. The key selling point here is the internal servers initiate the network connectivity to the 'reverse proxy' server in the DMZ.

So, this:

 [EXTERNAL]       [DMZ]        [INTERNAL]

 Client -->  ||    S1/S2    || --> DB,MQ

...is being replaced by this:

 [EXTERNAL]       [DMZ]        [INTERNAL]

 Client -->  ||      RP     || <-- S1/S2 --> DB,MQ

RP is essentially a stripped down version of S1/S2 (same technology stack). It conveys the external request to S1/S2 over a persistent connection initiated by S1/S2.

My question: Given that technology stack for RP is identical to S1/S2 (same tech, less code) -- how does the new setup confer significant additional protection?

Won't application attacks get through to S1/S2 unmolested? Specifically, if you compromise RP, you can compromise S1/S2 too. Won't this actually worsen the risk profile (since S1/S2 are now in the internal network)?

---

Adding some info and expanding on a point above:

1. The load balancer ('LB') is essentially transparent in this setup (i.e. RP is not a LB). For various reasons, LB cannot terminate inbound requests in any way.

2. Personally, I'm very skeptical of the security RP adds. My reasoning: if RP is somehow fully compromised (e.g. buffer overrun/shellcode), its an easy ride over the connection to S1/S2 in the internal network (doesn't matter who initiates the connection - its there), and then a similar exploit on S1/S2 (thanks to similar tech). The problem now is worsened because the compromised S1/S2 are now sited in the soft underbelly (i.e. the intranet), instead of the DMZ.

Answer 1

While different technologies for the front and back end give a nominal increase in security the amount is quite debatable. Put simply, just because the front end is compromised doesn't in and of itself mean the back end or any other art of the network is compromised. Although it can be argued that whatever method was used to compromise the front end can now be implemented on the back end it doesn't necessarily mean that method will be effective against the new target(s).

With that said, if you have pretty much the same systems and configurations for both front and back ends then yes, you do gain extra security by using a different technology for one of them.

Whether you use the same or different technologies, I suggest using different accounts on each system.

Answer 2

First, most load balancers function as reverse proxies wikipedia f5 devcentral. However, there are differences in protection inherent in how the load balancers (or reverse proxies) are architected. Note: i'll use the term "load balancers" (LB) and "reverse proxy" (RP) interchangably going forward.

A LB provides added security by serving as an intermediary for all communication. Most enterprise-grade LBs act as layer 7 proxies. For web traffic, the client-side HTTP session terminates completely at the LB and the LB re-establishes the server side HTTP connection back to the server. By forcing a layer 7 (l7) termination, the entire payload can be reviewed, scrubbed, and sent back to the server clean and optimized. In many cases, a LB also implements a web application firewall as an add-on module to further inspect the traffic for anomalous patterns before sending the traffic back to the web server.

The relative strength of protection provided by a LB in the model above depends on whether traffic is being terminated at l7 or a lower level. Some load balancers may only work at the network layer, which basically means the LB may just re-write the IP/port info as the traffic flows from client-side to server-side. In addition, it's entirely possible to configure a LB capable of l7 full proxy to work just on the network/transport layers to improve performance (l7 termination is resource intensive). In such a case, the load balancer may not scrub the traffic as thoroughly as possible.

Going back to your model, if RP=LB, then from an architecture perspective, the proposed architecture adds additional complexity than the current model. However, the key here is with the proposed model, the S1/S2 initiates outbound connection to the DMZ. An attacker can compromise RP but not be able to establish a new session back to S1/S2 or the internal network. However, if there are application weaknesses in S1/S2 or DB, MQ, an attacker could foreseeably tunnel back into the network to access S1/S2. Further, since "RP" is using the same tech stack as S1/S2, any weakness in S1/S2 would likely exist in "RP" as well. However, if "RP" isn't breakable, then the proposed model increases the security posture in that S1/S2's network stacks are protected and the attack would have to target the application stack first.

Though it's arguable the security value this model adds (if an attacker breaks the dmz/int fw, then they have open access to intranet && this model doesn't protect against the common spear fishing attack), such a model might be more acceptable to a compliance guy than not. This is especially the case for PCI compliance where any system that has access into a CHD environment is also in scope. In the above case, the entire DMZ could be in-scope, but if you establish a connection outbound from the CHD environment, then only "RP" would be added to scope. Though I'm not implying this is the case, I've seen architects approach PCI scope reduction this way.