Remote openhab binding. Questions about security?

Dear all,
I have a general question about security using OpenHab with several Bindings. Maybe you can give me a hint about best practices or overall system architecture.

My Home network is divided into several LAN networks as well as VLANs, which by design have different trust levels. While my Openhab , which is connected to an KNX Bus, belongs to the components I trust. there are many devices in my home that could be in principle connected to OpenHAB but belong to network parts with less trust level.

My question is: Is it a good idea to run two OpenHAB instances, one main instance with all trusted and one with all untrusted devices and controlling the interface between them to achieve a more secure setup? Can I use the Remote OpenHAB binding or should I prefer another one e.g. MQTT?

I am aware that the best solution would be no connection (as it is at the moment) but maybe there is a way to design a reasonable secure solution.

Thank you in advance for your help.

Best regards

There won’t be any generic advice possible without knowing what it is you are trying to mitigate. What risks are you trying to avoid? What threat actors are you concerned about? What “bad things” are you trying to prevent or reduce the impact of?

“Secure all the things!” isn’t going to result in a very robust or even secure system.

So without knowing what your specific concerns are, it’s all but impossible to say what approach would be better or worse or whether MQTT would be better or worse.

It’s not bad to run two different instances of OH but as soon as you connect them using either the Remote add-on or MQTT you have now exposed your “trusted” network to a less trusted network. Is that a problem? :person_shrugging: 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).

It’s definitely possible to design a solution, but you’ll have to design the solution and for that you’ll need to define the problem in the first place which means identifying what risks you have (don’t forget risk = likelihood * impact). Then you can rank your risks, decide which ones are worthy of mitigation and design an approach that mitigates those things that are most important to you. Obviously some compromise will be involved.

Personally, from what you’ve described so far, your network is way over engineered for a typical home network. A pretty common secure home system would include only two VLANS, one for IoT and one for personal use. An openHAB instance would bridge both networks, or it just lives in the IoT network. Devices on the personal network can reach into the IoT network but IoT devices cannot reach into the personal network (firewall rules). Ideally, IoT devices can’t even see each other on the IoT network. Access to the Internet is also strictly controlled for IoT devices.

1 Like

At first, thank you very much for your answer. Indeed “Secure all things!” is not a good approach so I will try to specify my thoughts.

What risks are you trying to avoid?
Illegitimately simplified: I want to avoid that a security bug in my old vacuum bot, that no longer receives firmware updates, would give someone the chance to open my garage door and enter my house.
Within my actual setup the OpenHAB instance is not only connected to “some lights”. Among many others it has access an alarm system, at least one door lock, presence detectors as well as the heating system. As i consider these systems worth protecting more than the majority of my other network clients, I took measures to restrict the access to the OpenHAB instance following the approach of compartmentalization. Until now this approach works fine for me accepting the fact, that some of the “untrusted” devices (e.G. vacuum robot, kodi media center, smart tv, devices that do not receive firmware updates) are not connected to OpenHAB via binding.
Still the possibilities of OpenHAB together with its many Bindings are very interesting and I try to figure out if it is worth opening my system.

What threat actors are you concerned about?
If someone wants to break into my house they find a way without a sophisticated hacking attack, that’s clear. Still, following the TechNews about IoT security incidents is not wholesome at all. Do I think the NSA wants to hack me, or if they would I could defend myself? No and no. Do I trust the thought: “Nobody has any interest in my stuff, so I do not need to set passwords …”? Also no. I am aware that my opinion is a subjective one and I understand and respect everyone who prefers another approach. I don’t know if additional security measures like I plan are needed in the future but I would like to try to implement them.

What “bad things” are you trying to prevent or reduce the impact of?
The thing I want to avoid is that an untrusted device can send commands of any form to a trusted device. I thought of controlling the interface between these two groups by setting up tow instances of Openhab and filtering the traffic from untrusted to trusted. The filtering shall reduce the surface of possible attacks compared to system that is not divided into two instances. If that is not the case the division into two instances will have no advantage for me.

Is it possible to filter the communication between two OpenHAB instances via Remote Binding. Is it possible with other bindings maybe MQTT?

I hope I could make my thoughts more clear. Also I am open for suggestions as well as criticism

Best regards and again thank you for the honest and open discussion.

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.

I think running two OpenHAB instances is a good idea. This will allow you to isolate the trusted devices from the untrusted devices, which will improve the security of your overall system.

The Remote OpenHAB binding is a good option for connecting the two instances. It’s a secure protocol that uses TLS encryption to protect the data in transit.

Another option is to use MQTT. MQTT is also a secure protocol, but it’s not as widely supported as the Remote OpenHAB binding.

Ultimately, the best way to secure your OpenHAB system will depend on your specific needs and requirements. However, I think running two instances and using a secure protocol are good starting points.

Here are some additional security considerations for your OpenHAB system:

  • Use strong passwords and enable two-factor authentication.
  • Keep your software up to date.
  • Use a firewall to restrict access to your OpenHAB server.
  • Monitor your system for suspicious activity.

Additionally, I think it’s a good resource for understanding the security considerations for IoT projects.

I’m not sure I understand this statement. MQTT is fully supported in OH and more widely used than the Remote OH binding. The MQTT binding is one of the most capable and mature bindings in all of OH.

1 Like

From the generic way it’s written and the brand-new account, this feels like an AI bot.

It did seem pretty pretty generically written but I tend to give users the benefit of the doubt. I didn’t look at that link though. Looking at it now I don’t see anything security related. I also don’t see anything nefarious either.

I’m thinking I’ll leave it for a day and if there is no response from @Rashmi_Singh I’ll take action. It might be some new SEO campaign to boosts search engine rankings or the like.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.