The biggest thing you’ve left out in your description is the likelihood. How likely is it that someone will hack your vacuum bot to open your garage or disable your alarm? Usually this is represented as a percentage over a time period, e.g. it’s 10% likely to happen in the next year.
What’s the impact if they did? (Money is a common way to represent impact but any number meaningful to you is reasonable).
An unlikely attack with a big impact might be worth mitigating, but the mitigation is limited by the likelihood. A likely attack with a minor impact is probably not worth mitigating.
Mitigating involves reducing either the likelihood or the impact of a successful attack and the mitigation should “cost” less than the risk, which remember is impact * likelihood.
And I’m not asking for you to do that analysis here. But you should do it for yourself because I think it’s still a bit fuzzy in your mind specifically what your concern is and what the impacts are. Use a spreadsheet. Come up with a list of threats (note that threats are not always human, they can be weather, animals, etc.). Come up with a list of attacks those threats might make against you and the impacts. Decide the likelihood that threat will attempt and succeed at the attack. The impact times likelihood becomes the risk score. Sort based on the highest scores and mitigate them in order.
I don’t know where you live and whatnot but the likelihood of some random attacker hacking one of your IoT devices to open the garage or disable your alarm is probably pretty low. But the impact is high so that doesn’t mean it’s not worth mitigating at all. But your mitigations should be comparable to the risk. A low risk should have mitigations that do not take too much effort to build or maintain. For example, does your vacuum require access to the Internet to function? If it’s not getting updates any more it certainly doesn’t need access for that. If not, the mitigation can simply be to block that device’s access to the Internet. Direct access to the device from the Internet should already be blocked.
Much higher likelihood attacks involve hacking your device to cryptomine, join it to a bot herd for DDoS attacks, or as a beachhead to get on to other machines on your network to steal your information or do a crypto ransom attack.
Not really but depending on which instance of OH is running the Remote add-on it is one direction. The instance that runs the add-on subscribes to the event stream from the remote OH instance and interacts with it’s REST API. The remote OH instance does not subscribe back nor interact with the other OH instance (doesn’t even know it’s there really). So it’s not likely that the remote OH instance can open your garage if it doesn’t know anything about your garage.
However, all events and Items on the remote OH instance does flow to the local instance. There’s no filtering of it.
MQTT works as you set it up. If you use the MQTT EventBus implementation, you can somewhat control which Items get published and subscribed to through Group membership. But ultimately MQTT works by setting up topics and messages. What gets published to or subscribed to is based on that.
However, have you actually mitigated anything by moving to MQTT? Or have you just moved the problem from OH to Mosquitto (or what ever you choose to use as the broker)?
There is only one way you can achieve this. There can be no communication between the networks. Period. However, you can reduce the likelihood or impact of this , possibly by quite a bit.
But as long as you can route IP packets from one network to the other, it will be possible for an untrusted device to send commands to a trusted device.
But again the likelihood aspect is important. What’s the likelihood that someone hacks your untrusted device and actually wants to send a command to your openHAB? Certainly not zero but the likelihood is greater that they want to compromise the OH machine so they can get onto your trusted network than that they want to physically break into your house.
There is a huge amount of room between VLANS and firewalls with complicated rules and leaving everything open. You need to find the right balance. I don’t think you have that balance yet but I’m not you and can’t do the risk analysis for you. But the mitigations in place and proposed seem much more than the risks they are mitigating.
Also, don’t forget opportunity costs (e.g. because of a mitigation you can no longer do something you want to or it’s significantly more expensive to do so), the value of your time, and the value of learning. I’m all for going overboard on mitigations if one of the purposes is to learn something.
Finally, understand this isn’t a set it and forget it situation. You’ll need to monitor your system to see if your mitigations are working and periodically reassess your risks and adjust accordingly.
Are you worried about someone on the less trusted network controlling your lights? Then it’s probably a pretty big problem. If you are worried that an IP camera is spying on your network traffic, it’s probably not much of a problem at all (assuming you’re using HTTPS/TLS).