I’m sure many users wonder why I am so forcefully against the average home user exposing their OH or any other service directly to the Internet whether you are running your own locally hosted instance of the openHAB Cloud Server, using a reverse proxy, or heaven forbid OH directly. This article describes one of the big reasons why.
Depending on where you are in the world, you will be found within an two hours and once found your service will be under constant attack.
Over the course of a 30-day period, there were 953,736 brute-force login attempts against the most highly targeted honeypot in Ohio.
Before exposing anything on your network directly to the Internet you have to ask yourself:
- Are you willing to monitor something that gets attacked up to a million times a month?
- Are you willing to monitor CVEs and the github repos of the service that you are exposing for security updates and upgrade accordingly? I guarantee you the malicious actors are.
- Are you willing to take active actions that can help prevent or mitigate attacks should they be successful such as putting this exposed service in an isolated network (i.e. DMZ), installing Snort or Bro or some other intrusion detection system, hardening the OS the service runs on with monitoring (e.g. Tripwire) and/or MAC (e.g. SELinux)?
- If you do discover a successful attack, do you know what to do to stop it and prevent it in the future?
These are really big jobs that take a lot of time and skill. Most home users, even technically competent users, do not possess the willingness to spend the time and effort to do all of the above and IMHO, not doing all of the above is an unacceptable risk.
I agree with a lot in the article. Personally I use openvpn to connect to my home network. It’s really easy to setup and also considered very secure. I even have my family running openvpn on their clients to connect to the home network. In my opinion I don’t trust myopenhab and similar services. If you do use that I would recommend to use a more advanced router/firewall like pfsense/opensense with geolocation filtering. Only allow connections from your own country and isp.
Even OpenVPN requires the steps I outlined above. Keep it up to date. Monitor it. Keep aware of known security vulnerabilities. And put in place other mitigations so if someone does get into your network, it isn’t easy for them to do much.
Monitoring includes checking periodically for connected clients and its internal routing table. Review the logs for login in attempts. Maybe set up Snort to monitor for scans and connection attempts on the OpenVPN port. If you are running OpenVPN on a regular host you should set up fail2ban to block IPs that are attempting brute force attacks. pfSense doesn’t support fail2ban but you can get the same using Snort or setting up special rate limiting rules in the firewall.
Good security hygiene with OpenVPN also includes requiring certificate + password authentication and periodically changing out the certs and passwords (maybe once a year unless there are other indicators).
This doesn’t make much sense to me. With myopenhab.org, your openHAB instance initiates the connection to myopenhab.org. Unless you are going to set up geolocation filtering to prevent your OH server from connecting only to servers in certain countries, which I suppose could do something, I don’t see how it really mitigates much, and it would be a real pain because you need to deal not just with the connection to myopenhab.org but any other outgoing connections (e.g. apt for updates).
I would like to take this opportunity to discuss a potential risk in the openhab cloud architecture. To my understanding the openhab cloud is a way to access your server when you are away or enable other services to control your devices with simple integrations(Alexa, Google Home). The part that I don’t understand is why the cloud instance has full access to the API and the paper ui. Having access to the paper ui = having shell access as the user running the openhab server. Why provide all this functionality if it poses a security risk? Me personally, I would feel a lot more comfortable knowing that the cloud instance can only control my setup and not modify it. I am interested to hear your opinions.
There currently is no authentication and authorization for the REST API. It’s all or nothing. Either you have access to the REST API or you have no access to the REST API. BasicUI and HABPanel use the REST API to function just as PaperUI does. Without access to the REST API there is no functionality at all.
Until and unless such fine grained control is implemented on the REST API, that is all that can be done. The openHAB Cloud Connector only serves as a proxy for the REST API. Luckily implementing some sort of authentication and authorization is stated as a priority for implementation in OH 3.
“Security risk” is going to be specific to each individual user. Is this too much risk for you to accept? Perhaps. It’s a hell of a lot less risk though then putting your OH on the Internet. I’d argue that for most users it’s a hell of a lot less risk than hosting OH behind your own reverse proxy that adds authentication. But it’s not zero risk (ignoring the fact that there is no such thing as zero risk).
And indeed, it does give shell access to the user running openHAB. But, unless you’ve gone and done something like give the openhab user sudo permissions, there isn’t a whole lot that the openhab user can do on the shell. That’s one reason why I’m really not in favor of giving OH permission to do things it shouldn’t which pretty much means no sudo permissions and don’t run it as root.
You can do other things to help as well such as running OH in Docker which can limit the damage that could be done should there be a compromise.
And users of myopenhab.org should also review their logs periodically for signs of unauthorized remote access, just as with any remote access.
If you don’t trust myopenhab.org, don’t use it. No one will think less of you. But your options are somewhat limited and they all involved either trusting some other third party service or punching a hole in your firewall.