OpenHAB internet accessible - co-developers needed

Setup, Configuration and Use Installation
1

Started with OpenHAB a while ago as a user of it, but I’m at the point I want to really open up my OpenHAB, Synology box and maintenance to the internet. I’m probably not the only one so I like to ask people to join in to the endeavor to open up with max security. Nowadays we have cacert.org or letsencrypt for easy certificate generation, through reverse proxy a lot can be done. But wouldn’t it be nice to set up a full how-to for all those enthusiastic OpenHAB users to get the full secure access to develop, maintain and use of their home network.
I’m not fully qualified to do this, so I seeking a few people who like to help out with this.
Don’t know if this is the place to ask this, but guess the moderators will step in if I was wrong.

Interested?? reply or PM me…
Cheers

2

openHABian already comes with the option to (automatically) setup a reverse proxy.
Ok I don’t know if it openHABian can easily be applied to a Synology and I don’t want to stop you from going ahead with this, but for most people (to use a Pi, usually, or a PC) this already does what you’re about to “develop” …
Or do you mean to integrate that functionality into core openHAB ? Given the aforementioned setup works fine, there’s no real benefit in that and I guess if there had been, someone would probably have already implemented that in the course of the last 3 years since OH2 came out.

PS: there’s no moderators to supervise postings.

3

Thanks for your response, great argument indeed. On the other hand, someone has to start. I’ll overthink my endeavor.
Cheers

4

There are several approaches and I believe all the OH ones are fairly well documented. The problem is you want to open up more than just openHAB and I think you might get better support for those on a Synology forum.

For OH you can do any of the following (in order of preference for users who don’t know what they are doing):

For everything else I would recommend setting up either OpenVPN (or some other VPN) or ssh tunnels to connect.

I tend to be more conservative on these sorts of things so I would not recommend exposing your Synology box directly to the Internet, even through a reverse proxy, unless you are prepared and capable of monitoring and reviewing your logs to recognize if/when your server becomes compromised. And you typically want as many layers of protection between your data (i.e. NAS) and the Internet as feasible.

In a commercial set up you would typically have a DMZ:

                                               DMZ
                      |            |      SSH, OpenVPN       |            |
internal network <--> | Firewall 1 | <--- Login servers ---> | Firewall 2 | <--> Internet
                      |            |      Reverse Proxies    |            |

Firewall 2 limits what IP addresses can connect to what ports from the Internet and only forwards approved connections to the servers in the DMZ. Firewall 1 only allows connections from the machines in the DMZ on the approved ports to connect through to the internal network. Of course strong authentication and authorization is set up between the DMZ and internal network, often using PKI certs, and the DMZ servers are constantly monitored and refreshed to identify compromises and clear them out.

Note that the DMZ and internal network are on different subnets with different IP addresses.

This sort of setup is not really tenable for the home user, but it is one of the standard ways you would do this.

2 Likes
5

Wow, just made my endeavor more interesting. Tnx for this great explanation.

6

I cannot follow your argumentation. The present situation after 3 years is a pity and a big shame and no success at all. While this used to be a feature of OH1 since ever even now OH2 is stil absolutely “naked”. Of course the setup of a reverse proxy as an additional third party component helps, but this is just another additional configuration step which is necessary because of a functional lack in OH2.
Apparently the cumbersome configuration work for this seems to be somewhat automated when using openHabian but all other users need to do it manually (I am running OH2 on Windows and spent a lot of time when I first set up nginx for this while I was asking myself all the time why the OH1 feature has been thrown away…).
So I also would like to see security features directly shipped and integrated with OH2.

7

The issue is open and ready for a developer, any developer to implement. If it were easy I’m sure it would have been done by now. Care to take a try at implementing it?

Personally, I’d recommend using a tested and popular webserver (i.e. one that has been tested in the real world with many actual deployments) to implement authentication and authorization for anything exposed to the Internet over something hacked into Jetty.

There are lots of reasons and uses for authentication and authorization even on a local network which is probably why the issue remains open to add it. But if you want to expose OH to the Internet, you should be using nginx or apache anyway.

And if that is too difficult for you given your skills or knowledge, you shouldn’t be exposing your OH directly to the internet in the first place as you lack the skills and knowledge to monitor and identify when it is under attack or has been compromised. Instead you should be using myopenhab.org or deploying your own instance of the openHAB Cloud (the instructions show how to set it up on a free AWS server).

That’s just my opinion, but at least it is an informed opinion.

1 Like
8

I agree with Rich.

Btw, OH1 did not have TLS implemented, just access control based on user+ip addresses. And while I also disliked that it was dropped in OH2, I guess that feature wasn’t deliberately ‘thrown away’ but probably was too difficult to re-implement after moving to Karaf/new jetty/whatever changed in OH2 (if it had been simple, I bet developers would have kept it).
Again: I wouldn’t mind if someone jumps in. But I still feel my argumentation to be valid: if there had been a (relevant amount of) need, someone would have well already done it. And you can move to openHABian, too, or put up Apache or nginx. Granted it’s definitely not a no-brainer and can be annoying to set up, but I tend to agree with Rich there as well: if you’re lacking the skills to get that working you shouldn’t be exposing your server to the inet and resort to myopenhab.

1 Like
9

While I can also follow your and Rich’s argumentation from the perspective of a longtime OH user (and for myself I also have set up nginx), I still find it weird for new users and beginners. New UIs have been developped that pretend to make the setup of OH easy even for noobs but for the most critical feature of security for external access nobody cares for years now. I know that it is a community project and so on and that you have to find volunteers (and I am sorry, implementing this is unfortunately beyond my skills). But if we want to have a real solution also for beginners than the current status is not satisfying at all. And your first post sounded a bit as if there was no need for improvement and that was just my point where I object.

10

Wish for - yes, need for - no.
But that’s a question on the point of view. You should not restrict yours to OH software.
As a openHAB_ian_ contributor and advocate, I recommend to deploy openHABian to EVERY new user, and it relieves (a bit) from the difficulties of fully understanding and properly setting things up all by themselves on nginx generic config level.
Your own situation as longtime user but still on Windows probably isn’t a representative point of view I guess, new users should not start with neither Windows nor plain Linux. If they still choose to, I expect them to also be aware of the consequences of doing so, i.e. the need to manually set up safe internet connectivity which means reverse proxy.

11

True enough, but we do exist :wink:

I was very disappointed in the loss of basic passwording from OH1->OH2. But I do realise it perhaps gave a false sense of security. The web-world has become a more aggressive place, defenses more specialised.
I don’t really want a competent/interested OH developer re-inventing wheels that are available off the shelf, better things to be done.

The “cloudy” solution offered by myOpenHAB mirrors the way most commercial gizmo suplliers have chosen to solve the same problem for non-skilled users.

To be fair, a portion of new users will start out playing with OH on some old laptop or existing Synology or suchlike, before deciding to commit cash to a Pi - if at all.
And that’s as it should be be, OH is good at this.

12

As rossko57 indicated, we do have a real solution for beginners. It’s called myopenhab.org with the openHAB Cloud Connector add-on.

There are even instructions that are not that hard to follow for setting up your own instance of the openHAB Cloud server on a free AWS instance.

Adding authentication and authorization to native OH is not a solution to allow new users to expose their OH instance on the Internet.

That being said, there is a real need for authentication and authorization in OH. Many users have requested for the ability to control access to certain parts of their OH (e.g. protected sitemaps, protected parts of sitemaps, etc). So indeed this is a real need for this support. But none of the use cases are “new user” use cases.

Only we give you the tools to run your own instance of the cloud so at least you can host your own. The the thing that is being attacked and exposed to the Internet be a server that isn’t on your home network and not even something you have to own. You really want more than one degree of separation between your home network and the Internet, particularly if you don’t know how to monitor and protect against the constant attacks.

One thing to realize, and it’s a common miss-perception, is that openHABian is only for RPis. You can and should run openHABian on any system using a Debian based Linux Distro. Just follow the manual installation instructions. I started on OH using an old lap top running Ubuntu. Had it been around at the time, I would have used openHABian on that machine. openHABian does commit the user to using a Debian based Linux Distro though.

13

It was not my intent to get a principle discussion on this topic. And I agree that if your not able to cope with monitoring and countermeasures having your own home network exposed is a bad idea.

For every interesting appliance in my home there are cloud connectors. But also their are several users with different skill levels and different trust levels.
I started a discussion on it with some colleagues who are network security specialists and they stated that using a cloud connector is a very good idea for most users, however fully trusting the connector (being of special interest to most hackers - like dropbox found out) is a false trust. They stated that is is good practice to protect also your own application against a failing security of the connector. Making a hack on your personal network labor intensive where there are a lot of other unprotected applications free for access.
Therefor even if openHAB is in your private network, TLS and authentication should be considered.
I understand that Jetty can also be configured for HTTPS and mutual authentication, introducing a stronger pki structure. Even if you decide not to use it, it might be an interesting point for investigation how to implement.

In my humble opinion the access to my home appliances something I really want to have secured the best I can. So I’m a little surprised to hear there are no use cases focusing on risk reduction of breaches. But I 'm willing to point the finger to myself as being too careful and too focused on security.

So for the first steps I will set up a nginx reverse proxy, ssh tunneling, monitoring and mutual authentication for my personal situation. In the mean time I already have some use cases to investigate, like how to fully reuse the z-wave security, scanning for intruding devices (what device do I trust and why), opening my front door with time-slot certificates that I can distribute to my visitors, revoking access and introducing a breach monitor thing/channel/item.
Seems I have a new hobby :baby:

So shall we close this discussion as being too focused on my wishes and if someone wants to work with me with similar needs, they know how to reach me? It looks to me this topic is something the contributors don’t need and have dismissed. Who am I to contradict their decision. I accept the denial.

14

That is a good point. And I think the main thrust of the discussion here is what is appropriate for new users and/or non-technical users. And for those users, their trust is better placed in using the connector then it is placing their trust in their own ability to configure, monitor, and mitigate risks on their own. Dropbox has a whole team of experienced experts to secure their system and they still failed. What hope does someone without such expertise have?

These are two different problems actually.

  1. Protecting OH from the openHAB Cloud.
  2. Protecting your other servers/services from openHAB Cloud.

Adding TSL and authentication to OH isn’t going to mitigate either of these risks. For 1, the openHAB Cloud Connector communicates directly with OH and with the openHAB Cloud server. Even back in OH 1.x that had authentication and authorization, you had to disable authentication on port 8080 so the Cloud Connector binding could talk to the server.

I don’t think that is still how that works. It might communicate directly with the event bus and internal APIs now. But in either case, adding the authentication there doesn’t protect OH from the openHAB Cloud because the Connector bypasses the authentication anyway.

All things considered, there are some serious security concerns even with the openHAB Cloud. For example, if you have the Exec binding installed, as many do, and you have given the openhab user blanket paswordless sudoer permissions, which so many people do, then someone who has access to your OH REST API can execute any arbitrary command on your OH server as root.

It also doesn’t help protect your other services and servers because all that means is there is some nominal authentication between the client and the OH server (i.e. your browser and the OH server) and the network traffic is encrypted. This mitigates your other services from monitoring your OH network traffic but doesn’t protect them from OH attacking them.

To protect your other internal services from OH, you need to enable TLS on those services and add authorization and authentication to those services.

There are all sorts of use cases for risk reduction. It is just that the vast majority of them do not involve OH directly. And even were OH to add authorization and authentication, these external methods of addressing the risk will be superior.

Not that security isn’t needed. It’s that the current solutions that involve external solutions like nginx will remain superior to anything that we will ever be able to implement in OH. So the incentive to implement something that is very difficult to implement is very low because no matter how hard we try we will never be as good as the solutions that already exist.

" I am pretty good at tennis , but I will never be as good as the wall." Mitch Hedberg

1 Like
15

Conclusion: it is more the complexity of implementation in combination with the availability of nginx that is safeguarding “enough” why for now further investigation can be postponed. The only warning will be: if you open up OH to the internet, please be aware that risks are involved. We don’t take responsibility for this.

2 Likes