2

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.

6
  • With all due respect to your security concerns: did you meanwhile find any feasible solutions for your RP? And for inverted HTTP connectors for your S1/S2 to be used behind the DMZ? Feb 19, 2014 at 3:50
  • Hello, no, I did not. I still hold this technical opinion. However, I do appreciate now that if a 'Client -> RP' request somehow managed to compromise 'RP', a subsequent 'S1/S2 -> RP' has a slightly different manage to infect
    – Happyblue
    Jul 5, 2014 at 5:06
  • (Continuing on .. comment limitations)I didn't find a feasible solution to the RP feasibility puzzle. I do appreciate though the infection modes are different. Lets say a 'Client -> RP' request leads to a 'RP compromise' (say, some SQL injection attack when parsing a malicious client request). For a subsequent 'S1/S2 compromise' the 'S1/S2 -> infected RP' request needs a different infection mode (i.e. an S1/S2 bug parsing the infected client response). But either is possible. If the exploit is via some low-level text parsing bug, an RP doesn't really afford much protection in that instance.
    – Happyblue
    Jul 5, 2014 at 5:28
  • (And on....)I'd say, the best 'RP architecture' may be a 'differential RP'. Here the RP is actually comprised of two or more systems: say, RP1 and RP2 - each, based on different technologies (say, Linux and Windows). Each stores the same set of rules on legally allowed request formats. Each gets one vote on whether an inbound request was valid or not. Any disagreements get the request blocked by the firewall.
    – Happyblue
    Jul 5, 2014 at 5:28
  • Hi! The latter idea sounds interesting... :) Do you mean that one will need a third component then - a "differential HTTP-level firewall"? Is this something already known? And did you mean a fourth component like "request splitter RP" to be used before two different RPs? Jul 6, 2014 at 3:46

2 Answers 2

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.

2
  • Arguably one aspect of security is decreased, as with two different stacks, HTTP Request Smuggling techniques may be employed to selectively target the front-proxy or the back-end server. owasp.org/index.php/HTTP_Request_Smuggling
    – Cheekysoft
    May 2, 2012 at 10:14
  • Personally, I'm very skeptical of replacing S1/S2 by a RP, particularly if all the RP does is forward the request to within the intranet. 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.
    – Happyblue
    May 4, 2012 at 1:09
1

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.

1
  • Hi -- I'm the guy who posted this question. Just adding some info: 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.
    – Happyblue
    May 4, 2012 at 1:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .