Does a DMZ make sense?

[150d]

Hi,

I can't make up my mind about how to design my home network:

Currently, I have a DSL router providing internet access through an integrated firewall, which routes into a DMZ, where OPNsense picks it up, firewalls it again and sorts the traffic into VLANs where my devices live. This gives me two firewalls: One inside the DSL router and one in OPNsense. The DMZ is not used for anything else (I have no servers placed there.)

Next will be changing my internet access from copper DSL to fiber. With that transition, the DSL router will be exchanged for a fiber modem. Now I could ...

a) connect the fiber modem directly to OPNsense, using the OPNsense firewall and directly route into my VLANs or

b) have a second, dedicated OPNsense box that takes the place of the DSL router, does nothing but "run" the fiber modem, provides the first firewall and routes into the DMZ as before. The other OPNsense would then tap into the DMZ and route into VLANs just as it does now.

I just can't decide what to do:

- Just having my OPNsense/main router handle the fiber modem would be the least hassle with configuration, best performance (no unnecessary hops) and best efficiency (no unnecessary devices consuming energy.) But it would only be "one stage" of firewall.

- Keeping the DMZ would be a more complicated setup, with two stage firewalls, at "first instinct" hightening security. But with it would come the drawbacks already mentioned and I'm not sure there even would be a gain in security: If one firewall can be bypassed by an attacker, why can't two? And if I route traffic inbound through the DMZ anyway, what does it matter if it has to pass two OPNsense or just the one? Additionally, the DMZ is not used for placing servers anyway, it's just a pass-through network that serves no other purpose than being a "buffer zone".

What do you think? Do you think a DMZ would actually improve security in this case, or am I just kidding myself?

Regards

[nero355]

b) have a second, dedicated OPNsense box that takes the place of the DSL router, does nothing but "run" the fiber modem

There is a huge chance that your new "Fiber ISP" will provide you either a XGS-PON ONT that will function as a "Bridged Modem" or if you are unlucky some kind of "All-in-One" Modem/Router/WiFi device that has a built-in XGS-PON ONT and does not have a Bridged Mode at all.

So having OPNsense with some kind of built-in NIC for XGS-PON Fiber isn't going to work sadly ;)

_{They do exist, but there is also a huge chance your ISP does not want to support them on their network!}

[BrandyWine]

Yes, DMZ's make sense.
If you have IoT , Wifi, etc, you dump them off into the DMZ network so that they dont have open access to your more private/sensitive stuff internally, and, you can create specific outbound rules for each device as needed. This is the safer approach.

A 2nd DMZ is also good when say you want to stand up a VPN server for remote access. Park the VPN server/device there.

The general model is to have anything that has a connection to internet (public) do so from a DMZ. Meaning your internal network stuff should use a proxy in the DMZ, this way the proxy is doing the actual connecting to public and not your internal stuff.

Seeing routable IP in a "netstat -na" is cringe-worthy. But, since vendors like to market things as easy P&P UTM etc they do not properly convey a good secure configuration.

Just need one OPNsense fw with multiple nics to make the secure setup work. WAN DMZ1 DMZ2 LAN.

[meyergru]

@150d: What you characterize as a DMZ is actually something different, namely a double-firewall setup. Thus, you mix up two questions here.

I would argue that a "real" DMZ, in the notion of having some (potentually exposed) devices on a separate network in order to keep them out of your internal LAN makes complete sense. By doing that, an attack could not proliferate to your LAN. This would only presume one leg (either physical NIC or VLAN) of one OpnSense to be separated.

What you propose instead has two disadvantages the way you decribe it:

1. This is a router-behind-router scenario with double NAT and all of its complications, e.g. port-forwarding must be configured on both firewalls. I would avoid it for the average setup.

2. It does not even have the benefit that some enterprise setups would try to reach by doing such a thing nonetheless: By using two cascaded firewalls of different kind, you could potentially harden your infrastructure against attacks to known vulnerabilities of one or the other. This is not the case with two cascaded firewalls of the same kind.

[150d]

These are excellent points. Big thanks, everyone.

I think @meyergru put it best: I'm NOT really thinking about a true DMZ after all, because I can't separate my devices properly. Currently I'm doing this with VLANs and firewall rules the best I can, because everything is awfully interconnected. For example, my "dirty" IoT devices also need to talk to the smarthome server, which needs to talk to my multimedia equipment, which needs to talk to a file server. That doesn't mean the IoT's need to talk to the file server, but I can't completely isolate the segments either. A home network may be more complicated than corporate in that way because the existing equipment will "have to do it all".

So the best I could do would be "router-behind-router", just as you said. But this wouldn't have much of a benefit securitywise, just be a more complicated setup.

I guess it comes down to a "gut feeling" thing: Connecting a raw modem directly to my main router, firewalled or not, just feels wrong. But the only additional protection I would get by pulling it out to a dedicated, second OPNsense would be configuration error, maybe(!): Even if I make a mistake in the firewall config of the main router, the second firewall on the dedicated "modem-runner" should still catch it. That is, provided the firewall rules are not just copied over (which I don't expect they will be.)


And thanks also @nero355 for your reminder about hardware choices (or lack thereof.) But that's covered, I will have a dedicated modem, either stand-alone or in SFP form factor. Most likely I will choose the stand-alone variant, since I read that SFP-modems can run a little hotter than I may be comfortable with.

[passeri]

@150d, when you describe what needs to talk to what, think also about which device initiates a conversation. Does it need to be either way? For example, my IoT net can reach the internet but no device on another LAN, yet this is no impediment to my private LAN devices being able to talk directly to the IoT devices to give commands or request information. Source for session initiation matters.

[150d]

@150d, when you describe what needs to talk to what, think also about which device initiates a conversation.

Well, take a IoT device that has a web interface for administration, but passes their sensor data by MQTT. If you put that into a DMZ, you would need one route to access the web UI from the inside net (no problem), but also a route from the DMZ into the inside net to reach the MQTT broker.

There is not much point in having a DMZ in the first place if you poke holes into it for every other device.

[Patrick M. Hausen]

Place the MQTT broker and the Home Assistant (HAOS) VM in the IOT network. Access HA and everything else from your trusted network unidirectionally.

Place everything that needs to communicate seamlessly in a common zone. That's at least my recommendation.

E.g. place your printer in the trusted network where your PCs are. Don't trust your printer vendor? Get a printer from one you can trust.

[150d]

Place the MQTT broker and the Home Assistant (HAOS) VM in the IOT network.

How will HA then access e.g. the database server? The DB I want in my internal net, not potentially exposed in the DMZ.

I would have to move much of my infrastructure from internal to the DMZ. About the only parts left would be the PCs I work on.

Even my file servers would need to be split into a "secure" and "non-secure" part, the latter of which moved to the DMZ. But these servers are exactly what I need to protect most.

On the other hand, if everything is in the internal zone (no DMZ at all) I can sort the devices comfortably into VLANs. I feel I'm more flexible with firewall rules between VLANs than I could be with routes between internal/DMZ networks.

[Patrick M. Hausen]

How will HA then access e.g. the database server? The DB I want in my internal net, not potentially exposed in the DMZ.

HAOS is a complete Home Assistant appliance, application, database, everything in one VM. That's the recommended (by the HA project) way to run it. I see no reason to separate the DB which is only used by HA from HA itself.

VLANs are a DMZ ... I am not getting your last sentence. As soon as you have two VLANs, one "trusted" and one with reduced access rights, you have a DMZ. At least as defined by the decades old defining literature on firewalls, i.e. Cheswick & Bellovin and Avolio & Ranum.

[150d]

HAOS is a complete Home Assistant appliance, application, database, everything in one VM.

I know, I have one running here. It would actually be one of the easier entities to relocate, since it isn't very widely interconnected. My main smarthome controller is ioBroker, and that has it's threads everywhere. For me, that's the beauty of it: Having data from all sources in one place. Even HA is but a sensor to ioBroker in my setup.

That's why I said that "corporate may be less complex": In production setups it's easier to characterize a system as doing either this or that. It either has internet access or not. It either needs user interaction or not. If you need one more job done, you put up one more system to do it.

In home networks, everything needs everything else. That's a bad place for applying corporate concepts like a DMZ.

VLANs are a DMZ ... I am not getting your last sentence. As soon as you have two VLANs, one "trusted" and one with reduced access rights, you have a DMZ.

My idea of a DMZ is is the hierarchic "a place between", isolated by routers on either end, with each segment able to reach the one "above", but not "below" itself. So the internal net could reach the DMZ, and the DMZ could reach the public net, but the DMZ would never under any circumstances be able to reach the internal net.

My VLANs are designed more "side-by-side", in that each VLAN may or may not reach the public net, and there are explicit rules for when a device from one VLAN needs to reach a device from another VLAN for a specific service (only). But these rules may go in either "direction" as required for the job.

Functionally not that different, yes. I wouldn't have called my VLANs a DMZ, though. But surely that's semantics.

[Patrick M. Hausen]

My idea of a DMZ is is the hierarchic "a place between", isolated by routers on either end, with each segment able to reach the one "above", but not "below" itself.

That's a perfectly valid concept, IMHO. I use VLANs (of course) to implement that.

[meyergru]

What you define as a DMZ is in reality a "dirty DMZ" with actual devices between two routers. As such, it only benefits from the first router, whereas the LAN is behind both routers.

As explained, two routers of the same kind only bring more complexity, not more security and if you limit yourself to just one firewall, then it is the responsibility of that to separate the DMZ from the LAN.

There are many slight variations on this theme, so you have to explicitely say what you mean - that is what I referred to in my response.

Besides, with any kind of DMZ, you will find that more often than not, this sentence: "the DMZ would never under any circumstances be able to reach the internal net" is not true, either. Having build such setups for e.g. banks, I can tell you that e.g. logging must be able to pass to inside servers, among other things.

[Patrick M. Hausen]

In the context of a very security critical environment like a bank I would consider logging inside the zone/DMZ and pulling the logs from inside on a schedule. TCP connections favour directional thinking and you can effectively seal one direction shut while only using the opposite one.

Downside: depending on your schedule you might lose a couple of minutes of logs.

Then you can log to yet another separate zone to a dedicated log device.

Always a question of cost and effort vs. effect.

[meyergru]

As I said, there are other services that need to be accessible, logging is just one example that is obvious that I can mention. When you think more than a second about the application at hand, you will notice how it cannot be done with inside-out-access only... ;-)
Of course all of those services are themselves not on the LAN, but in separate security zones.

What I want to point out is that even with very strict security requirements, there is no such thing as black and white. I remember dicussing a full fledged firewall setup of this kind back in 1997:

You cannot view this attachment.

Where each of the three firewalls was supposed to be a dual-homed gateway with two routers and an intermediate appication-level gateway:

You cannot view this attachment.

Guess what? This was severly downscaled in reality...