What's the point of a DMZ if it has access to a DB inside inner network?

Question

I understand that you place public facing servers in a DMZ and so if they are compromised, it doesn't compromise the inner network. In order to do so, the outer firewall forwards ports (80 and 443 in my case) to web servers. From this, I understand that opening ports = allowing untrusted traffic to come in.

However, in the case of a two firewalls DMZ, you place a DB server in the inner network because it doesn't need to face the internet (I get that). If one of these web servers needs access to a DB in the inner network, the second firewall will forward a port from this server to the DB. I found that allowing DMZ systems to connect to systems in the LAN is inherently risky. which makes sense. By forwarding a port to the internal network, doesn't it make the inner network opened to attack if the DMZ gets compromised? If so, what's the point of a DMZ? Is it just to add an extra layer?

I am using a reverse proxy, so my web servers aren't directly accessible from the internet:

• Should the reverse proxy be the only server in the DMZ and forward traffic to web servers in the internal network through the second firewall?
• Is it really unsafe to place a database, which has no port forwarded to, as long as the reverse proxy doesn't redirect anything to it, in the DMZ?

I came across these diagrams which makes the design much clearer. But why isn't the network designed like this?

  *untrusted*         Internet
       |
====Firewall====
       |              DMZ
 Reverse Proxy
       |
====Firewall====
       |              DMZ2
   Webserver
       |
====Firewall====
       |              DMZ3
   DBserver
       |
====Firewall====
       |              Internal Network
   Employees

I guess because it implies a lot of firewalls and it might be unnecessary but where's the middle ground with this design (we can imagine 3 or even 4 separates VLAN for the reverse proxy, DB and/or web servers and LAN)?

              *untrusted*
                   |        
      ==========Firewall==========
      |            |             |
Reverse Proxy      |         Employees
          DBserver - Webservers

Thanks in advance!

Answer 1

The main aspects to consider in this case are defense-in-depth and security by design. As you rightly point out, adding layers after layers of firewalls and port forwards does increase complexity but does not defend against attacks on its own.

A successful attack is a function of time and effort, therefore anything can be compromised. Having this in mind requires you to do your threat assessment and consider the impact and likelihood of compromise of every network and every system as well as the collateral damage that arises from it.

Using your example, you use a DMZ to contain lateral movement of attackers in case of a breach. Critically, lateral movement will happen using any network and any protocol that happens to be exploitable or compromisable by leveraging previous attacks. Therefore it makes sense to minimise the scope of connectivity of a server in a DMZ -- this would be your web server. Your port forwards on the perimeter firewall ensure that the only way to access the web servers from the Internet is via the web server ports, so again you are limiting attack surface from the Internet. In addition, you will want to ensure that the server is securely configured and that no other services are exposed in addition to those that absolutely must be exposed, and if you can, limit them using a host based firewalls to specific IP addresses further from within your network to ensure it is more difficult to be attacked from within the DMZ.

Should the web server require connectivity to a database, which it often does, then rightly so you need it to be able to contact that port. This is not a security weakness, but an operational requirement. You can either have the server on the same DMZ as the web server or in a different one. The latter is more effort but arguable better security. Again considering the database server, you'll want to harden its configuration as much as possible including using host based firewalling. The database should also be configured securely with the web server using multiple accounts with strong passwords (as opposed to using a dba account with a weak password because "it's internal"), etc.

With all this in place, what you end up with is far from being an architecture that is impossible to break into, but it is one that you have made as difficult as you possibly can to attack, compromise and move laterally from.

To compromise the database server (provided the attacker hasn't done this via the database connection on the web server), an attacker would need to somehow compromise the web server first, then proceed to attack the database. The database server needs to be weak enough (or vulnerable) to be compromised too.

Answer 2

Let’s step back and revisit the concept of DMZ.

When speaking of most things, especially technical things, we are always using some form of analogy. These analogies are handy for quick reference as long as we remain at a level and understanding appropriate to the analogy. Every analogy will break down if we probe deep enough.

We often say, “The DMZ,” or, “In the DMZ,” as if it is a thing or place but it’s not.

When connecting a device (generally a server or router) to the Internet, the initial question is what ports do you want to Open/Allow.

The related question is, what do you want to do with attempts to communicate on ports other than those previously designated? If your answer is “Nothing or Block”, then you’re done, there is no DMZ.

The concept of a DMZ comes into play when you want to assign a server/handler for Other undesignated ports. The DMZ is a rule that says send these Other ports to my handler. Again, if you have no need or desire to handle Other ports, you have no need for a DMZ rule.

The analogy gets complicated, but not yet broken, when the Internet facing device is a router/firewall (yet another analogy). Here the initial port acceptance is (should be) accept no ports. To become useful, the Other port rules come into play. Designated Other ports such as 443 can be set to forward through to your 443 web server. This is not really DMZ as it is a designated port but many SoHo routers put this port forwarding control under a subcategory of DMZ.

DMZ is more undesignated ports. You could have a rule that says, “send all other ports to my special handler box”.

So some of your specifics:

“Should the reverse proxy be the only server in the DMZ”

The reverse proxy (often called a reverse server) is not a server at all, it’s a client. It has no static open ports forwarded from the router, only dynamic outbound initiated ports. No DMZ at all!

“Is it really unsafe to place a database, which has no port forwarded to, as long as the reverse proxy doesn't redirect anything to it, in the DMZ?”

It’s a non-sequitur. You have no DMZ and even if you had, the DMZ is a rule. With no forwarding rule to the database it’s not in a DMZ.

Here the DMZ analogy begins to break down. It has become common usage to refer to the network portion between two firewalls as a DMZ. It may or may not be as a function of the firewall rules.

If all you have is a database connected to your web server connected to your reverse proxy, proper port control should be all you need. No DMZ at all.

Realistically you may want another firewall between your database and the web server to try to protect against possible web server compromise, but this is unrelated to the concept of DMZ.