Can a load balancer "BE" the computer in the DMZ?

Question

I'm wondering if a web load balancer can take over the duties of what would normally be considered the front end server in a DMZ?

In our current environment, we have the classic DMZ setup as illustrated below.

Internet --> Firewall --> DMZ front end server --> Firewall --> Lan Server data

We have a new application coming online that does not have a purpose built front end server from the vendor. Although no data will live on this server, it will be located on the lan. When asked about how to make the application secure, their response was to use a reverse proxy as the front end.

So my question is this- can I simply use our web load balancer to be the "server" in the dmz? Does this pass the sniff test? Does this work in an audit?

Here is an illustration.

Internet --> Firewall --> Load Balancer --> Lan Server

The load balancer by its nature operates as a firewall as port numbers need to be specified. However, the inside interface of the firewall as well as all interfaces of the load balancer (single arm) and the interface of the lan server are all on the same lan network. However, the load balancer does end and create new sessions.

Or do I need to employ a reverse proxy and a load balancer as illustrated below?

Internet --> Firewall --> Load Balancer --> NGINX rev proxy --> Lan Server

The NGINX reverse proxy would do nothing essentially except exist and forward packets.

What really makes a DMZ? Is it two different subnets with firewalling that is most important or is it the termination and recreation of the session prior to reaching the lan? Or is it something else?

Another project I've been needing to button up is an open SSH to a server in the lan. It has no front end server, but we could potentially use the load balancer to serve this purpose, but only if it can legitimately pass an SOC audit.

Thanks for any meaningful discussion!

Answer 1

A DMZ is both of those things. It is the point where non-trustworthy known non-acceptable inbound requests are blocked (by an outer firewall), and non-trustworthy but potentially acceptable inbound requests are terminated and evaluated for potential re-initiation to the sensitive interior.

This evaluation process may lead to a compromise, so the subnet in which the application terminating the inbound request lives should itself be separate from the interior networks, potentially using another firewall for segregation. This request-terminating-application is also known as a reverse proxy.

So:

internet -> firewall -> reverse proxy -> firewall -> lan

For HTTP, the reverse proxy can be considered a layer 7 or application firewall. It should do protocol compliance and request sanitization and should support some defensive functions like blacklisting and malicious request signature functions.

For HTTPS, the reverse proxy terminates HTTPS, though traffic from the reverse proxy into the LAN may be re-encrypted.

The load balancing role can be placed in a DMZ, but the need should be evaluated. Load balancing is usually an application function that requires orchestration and coordination with application deployments, and is also logically downstream of the kinds of sanitization and safety-oriented functions that should occur in a DMZ.

So:

internet -> firewall -> reverse proxy -> firewall -> load balancer

In terms of trust boundaries, the internet is untrusted, the DMZ (where the reverse proxy runs, in between the two firewalls) is semi-trusted, and the lan, where the load balancer runs, is trusted.

Finally, nginx is versatile software that can support both reverse proxy/web application firewall and load balancing functions, and so often it will be the same nginx instance playing both roles- meaning load balancing is in the DMZ, though there also can still be a firewall between nginx and the application hosts.

So:

internet -> firewall -> nginx (waf and lb) -> firewall -> applications

That may or may not be fine, depending on the audit conditions.