VLAN's and openHAB

No, I’m just trying to point out that most people probably don’t need to expose anything, and they won’t get any “extra security” from subscribing to various ban lists etc. If you need to expose something, then you have to do whatever you think is “necessary”. I once had to expose an FTP server for a little while, and I was crazy worried about that, so I ended up restricting access only to whitelisted dynamic domain names. Not very flexible nor applicable in many situations, but I’m trying to say that you will just have to do whatever you consider an “acceptable risk”.

If I were to expose e.g. a web server today, I’d probably run only the web server on that computer/VM and isolate it almost completely from the rest of the internal network. You would need to have some access to reach the server from the inside, but it wouldn’t have to be able to reach anything.

To me, that would feel as an “acceptable risk” if I didn’t store anything sensitive on the web server itself.

Yeah. That is what I mean with have in parallel often outdated firmware versions (EoL) and therefore a good reason to isolate those devices in a separate VLAN and to control the point-to-point data flow by firewall rules.

Yes, fully agree, access limitations also required, among further measures.

For me, all of this is relevant as defense in depth. I recommend all of this in parallel, not as alternatives. But maybe, this was a misunderstanding.

I’m unsure how to interpret this DMZ, or to apply it to my setup. On the one hand, it feels like SWAG belongs there, on the other hand, the whole point of SWAG is to redirect. In any case, only ports 80 and 443 are open, forwarded to my NAS, on which the SWAG container is running.

It depends completely on how safe you’d like to be. If SWAG is a reverse proxy that is exposed to the outside, I would very much put it in a DMZ, but whether that’s possible also depends on your infrastructure. You’d need to have whatever runs the container support VLAN tagging so that this container would only get access to the DMZ, not other zones. And even if you do, containers aren’t really “safe” and can be broken out of, so I don’t know how “safe” such a setup can be in any case. I would put more faith in a VM, but that requires different infrastructure.

Then, you get to the “real problem” with a reverse proxy, it exposes something on the inside via proxy. So, you indirectly expose an internal resource, and you’d need to give SWAG access across the VLANs for it to work at all, undermining much of the “value” you get from separation. If it is OH that you expose publicly using SWAG, you’re still pretty much exposed in a much more “serious way” anyway. OH’s UIs are in no way “battle hardened” to be exposed to the internet, and I would simply never do that.

Isn’t the whole point of the cloud connector that you shouldn’t have to expose OH?

VMs are just as easy to break out of.

It is possible to compromise the service through the reverse proxy. If that happens what ever machine that service is running on becomes compromised. From that machine the attacker can move laterally to any other machine the compromised machine can reach.

So you would put the reverse proxy and any service reached through that reverse proxy in a DMZ. If the reverse proxy or the service is compromised, there is limited opportunity to move laterally because the DMZ is locked down with limited to no access to anything valuable.

Often, the reverse proxy won’t even be inside the DMZ but before it.

So you might put the reverse proxy exposed to the Internet with nothing else on the machine/vm through a firewall. Another firewall sits between the reverse proxy and the DMZ that only allows access from the reverse proxy to certain machine(s) on certain ports in the DMZ. If it’s a third gen firewall you can further lock it down via protocol and there are other things you can do too like requiring the reverse proxy and services mutually authenticate using certificates.

In the DMZ are the webserver portions of the services you run that are exposed to the Internet. Sometimes this is the whole service but other times the backend is split into a separate service.

A third firewall sits between the DMZ and your LAN. Once again this only allows traffic from the DMZ machines to specific LAN machines on certain ports. On the LAN sits your databases and other back end services the exposed services depend upon.

If the reverse proxy is compromised, it’s ability to get into your DMZ is severely limited and getting into your LAN is impossible (theoretically). If a service in your DMZ gets compromised, it is severely limited in it’s ability to get into your LAN.

It’s worth noteing the whole DMZ concept is considered kind of old school. Most enterprises will deploy some kind of zero-trust approach instead. But that’s really overkill for even a midsized business, let alone a home network. But it does increase the amount of work an attacker needs to do to get to your valuable parts of the network.

You could implement a DMZ using only two firewalls.

I think that’s untrue in general. I’m not saying that you can’t find a case of a very unsecure/badly configured VM that is easier to break out of as a very hardened container, but if both are configured “equally sensible”, I have a very hard time believing that.

I haven’t “gathered data” to back up that claim, because it’s in the nature of the two to me, but Gemini at least seem to agree with me:

Yes, there is a massive difference. Breaking out of a Docker container is significantly easier than breaking out of a Virtual Machine

…blah blah reasoning..

Summary of Effort

  • VM Escape: Requires highly complex, specialized exploit code (often costing hundreds of thousands of dollars on the exploit market) targeting hypervisors like VMware or Hyper-V.
  • Container Escape: Often requires just a single command line misconfiguration or a known kernel vulnerability.

I don’t run VMs with shared this or shared that, I configure their networks properly, and if you “break out”, you’re in a “bare bone” ESXi system where you can do very little. If you manage to get root access to ESXi somehow, I guess you can copy/clone virtual disks (lots of GBs to transfer) and gain access to the data by mounting it to a new system somewhere else. Except for that, the worst you can do is probably to delete VMs. It doesn’t automatically give you access to the “inside” of a VM even if you have ESXi root.

If you break out of a container and gain root privieges, you have full access to everything on the host machine and any other container.

I can’t “prove it”, but I consider VMs much safer - so much so that I have several VMs running just a single container. The only reason to bother with the VM “around” the container is the isolation.

I don’t know why you’d need “multiple firewalls”, I guess you can argue that it is an extra layer of security too, but I’ve always let the same firewall handle all this. The firewall has one network interface on each VLAN, and handles both routing and firewall rules between them. My idea is that if your firewall is compromised, it’s all over anyway.

Just to share my objectives and why I’m using vlan’s.

  1. initial situation was everything in the home network, then I wanted to isolate switches, IoT and Guests, so I’ve created 3 vlan’s, final setup being:
  • vlan 1 (network) - routers and switches
  • vlan 1000 (guest) - mobile phones
  • vlan 2000 (home) - servers (proxmox and NAS), family PC’s and mobile phones, media (TV, TV box, internet radio)
  • vlan 3000 (IoT) - openHAB, all IoT devices, containners and bridges. No internet access by default so I had to enable a local NTP service (tasmota MQTT requires NTP)
  1. Allow internet access to some IoT devices → firewall rules to allow a certain range, includes openHAB and some devices, such as washing machines

  2. Allow openHAB to access all vlans → another firewall rule

  3. Allow my own PC to access all vlans → another firewall rule

ISP router has a DMZ port connected to my OpenWRT router, where only two ports are open to the outside world (Plex and Wireguard). Network also includes TP-Link switches, Unifi AP’s, and one OpenWRT AP (it would be much easier to have Unifi or Omada for everything, including main router, but it would be more expensive).

My OpenWRT router can also connect to a backup WAN. This was usefull some years ago when the fiber service was down for 2 weeks.

If you are concerned enough to set up the DMZ in the first place, you should be concerned about your firewall becoming compromised. If you use the same one on both sides of the DMZ (I mean the same instance) compromising that firewall leads straight into your LAN. If you have two separate firewalls, ideally different ones, compromising the outer firewall only gets access to the DMZ, not the LAN. Getting to the LAN requires a separate compromise.

The whole purpose of a DMZ is to make it so one compromise is contained. To get to valuable stuff it requires at least two.

I get that, but a firewall is supposed to be pretty hardened in the first place. Also, I never allow any kind of access to the firewall itself from the outside. Compromising a firewall and a web server is in two different leagues of difficulty the way I think about things. If that idea is wrong, my whole “thought framework” falls apart. But, as said, I always minimize what has access to the firewall management interface itself as much as I can. Back in the days when I did this at companies, I typically only allowed the physically separately wired management network that access.

All I can say is Cisco hasn’t been having a good year on that front. Palo Alto isn’t far behind. I don’t really follow this space closely so can’t comment on other vendors.

There have been vulnerabilities to firewalls that do not require direct network access to the firewall. I dont’ know if any of the current know vulnerabilities work that way. I would hope not but :person_shrugging:

Given that in the home user space, your firewall is going to be your router is going to be your gateway all in one device (opnsense, pfsense, ddwrt, tasngled, fritzbox, etc). Very few home users will deploy a separate device for all these functions. Therefore, there is going to be a bunch of non-firewall related vulnerabilities present that can get to the firewall.

If that’s the case, it changes things. I run OPNsense on dedicated hardware that boots into FreeBSD. If your firewall is going to be virtualized, you might as well try to spread the risk by using different instances :+1:

I don’t follow that closely either, but a quick search for recent breaches seems to center around the authentication, and getting access to the firewall that way. I have no illusion that any “web interface” is safe, which is why I don’t allow attackers access to that at all.

So do I. But it’s also my gateway, router, DHCP server, DNS server, not to mention the administration stuff and monitoring stuff opnsense comes with. I do not have these all running on separate machines or even separate VMs.

And from a security perspective I’m fine with that. The cost of doing otherwise is greater than my risk calculation. That’s why I don’t have a DMZ in the first place yet.

But if the risk calculation does make it where setting up a DMZ is worth it. At a minimum you’d want the firewall protecting the internet side of the DMZ to be different from the one protecting your LAN and you’d probably want it to only be running the firewall, not a bunch of other stuff.

If doing that is too expensive (money and time) and it’s only doable if it’s all one device running a bunch of other stuff too, it’s probably not worth setting up the DMZ in the first place. Some other protection mechanism would probably be sufficient and way less expensive to set up and maintain.

But lets say that there is some vulnerability in unbound where a carefully crafted DNS request compromises unbound and lets an attacker drop a RAT on the box.

“But I don’t expose unbound to the Internet” one might say. True, but you browse the web right? What’s one of the first things that a browser does when you load a web page? Make a bunch of DNS queries. In order for unbound to have any use at all, it needs to be reachable by the devices on your LAN. So you can load a malicious webpage which sends a bad DNS request and now you have a RAT on your firewall and the attack came from inside the LAN.

Is there such a request today that can do this? Probably not. But we don’t know what vulnerabilities still reside in the software we run. If we did we would fix it. So we have to assume that vulnerabilities like these do exist and protect against them where the risk is warranted.

Given risk = cost of compromise * liklelihood this risk against unbound is relatively low because the likelihood is low. But the more services you have that must be accessible from your LAN in any way (DNS, DHCP, etc) the risk goes up. Exposinthe box to the internet makes the risk go way up. If your risk has risen to the point where a DMZ is worth it, that means it’s worth it to use separate firewalls. Otherwise setting up the DMZ probably isn’t worth it in the first place.

I don’t agree with the risk calculation, I agree that there are potential attack surfaces on the firewall as well. That said, I don’t use firewall as primary or secondary DNS, only as a tertiary “fall-back” DNS if the others are down. And I run none of that “analytics” stuff on the firewall, it’s left to do firewalling/routing, DHCP, backup DNS, and point-to-point VPN termination (I have RA configured but disabled since I don’t need it at the moment). In addition to that, it maintains a dynamic DNS registration and monitors the UPS so it can shut itself down before the battery runs out. I think that’s about it.

So, I’d say that the “exposure surface” is relatively limited, not non-existing, but magnitudes smaller than the “surface” an internal web server that is exposed represents. So, I think a DMZ is the only sensible thing to do if you want to expose something, I don’t expose anything at the moment, but when I do, I use dedicated, isolated networks/DMZs, not necessarily just one DMZ where everything is mixed.

To me, this makes sense. Ultimately, this is somewhat of a “guesswork”, because all somebody needs to do is to find one hole they can get through. If they do, the size of the “attack surface” doesn’t matter. And we don’t know every “weapon” that’s out there and what it can do, so all we can do is guess what the risk is and try our best to deal with it.

That said, for especially “valuable resources”, the firewall isn’t the only layer of protection. You can have all kind of authentication, encryption etc. on the individual devices/computers, which is also a part of the total picture.

I generally accept that if state-level attackers want to get to me, they probably will. They can just send people here to overpower us and take the information the want. There’s a limit to how valuable anything I have is. But, I’d very much like to keep the script kiddies, automated attacks and “opportunistic attackers” in check. That’s my goal, nothing more.