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.
[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:
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.
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.