Just a side note, I just installed fail2ban on a clean debian VM and within the standard jail.conf, there is already an openhab-section:
[openhab-auth]
filter = openhab
action = iptables-allports[name=NoAuthFailures]
logpath = /opt/openhab/logs/request.log
So would that mean that if you just include the fail2ban package as requirement with the normal openhab package, that you would get this basic protection out of the box, wouldn’t it?
I don’t know that the default openHAB config it comes with has been updated for OH 3. I think it’s still for OH 1.x. Someone should create a PR over there to use the new authentication built into OH 3. But I’m not sure now that I’ve experimented with it that this is going to work. At least not without some changes to the logging.
Firstly the failed login attempts are logged out to openhab.log, not request.log which no longer exists.
The logging message takes the form of:
2021-09-10 08:31:16.834 [WARN ] [uth.internal.AbstractAuthPageServlet] - Authentication failed: Wrong password for user rich
2021-09-10 08:31:25.663 [WARN ] [uth.internal.AbstractAuthPageServlet] - Authentication failed: User not found: wronguser
The IP address isn’t in the log. I can’t remember whether fail2ban requires that or not.
Over this weekend I’ll spend some time seeing how/whether it can be made to work and if not what would need to be changed in OH to make it work. But it appears that the default built into fail2ban is still configured for OH 1.x and not OH 3.
Interesting discussion. Most posts are about preventing openHAB to be exposed. While that mitigates most (but certainly not all) security issues, I think that is not the way to go. People want to access everything from everywhere at anytime. I would prefer to harden openHAB itself, I don’t know why one could argue against that. 
This is what most professional business tools did the last couple of years. From on-premise fully locked to local network tools migrated to cloud apps available to open (read evil) internet.
Some thing allready took place in openHAB. Removing secrets from logs, introducing new authorisation system and more. But it also needs a lot more work. it would be really interesting to create a list of all security related issue’s that are known if openHAB is directly available on a public ip and all ports are open.
Maybe something simple as adding a general security summary to every binding xml explaining the risks, ports or other things the binding adds, would be a first step.
We already provide a free service to allow that.
But I don’t think anyone is arguing that we shouldn’t make OH more secure and better. But security is a balance between usability/availability and security and we need to be conscious of that trade off and deliberate in choices made to ensure we don’t tilt too far toward security at too much cost to usability/availlability.
And even if OH were to be come best in class in terms of security, I can’t image we will ever recommend putting openHAB directly on the internet. Doing so comes with a responsibility to upgrade/patch and monitor that most users are unable or unwilling to do. And we’ve already provided a free service to enable this safely.
Very few organizations will expose these tools directly to the internet without also deploying a bunch of additional sensors and monitoring, stuff like NextGen firewalls, reverse proxies, Intrusion Detection Systems (IDS) etc. That’s not really reasonable to expect from home users. At a minimum a reverse proxy should be used which is approaching something home users can manage. But once you’ve done that most of the protections are implemented in the reverse proxy now. That doesn’t mean OH shouldn’t or couldn’t be more secure too, but it does put a finger on the scales when weighing between functionality/availability and security.
If we already provide a way to securely access your OH remotely and no matter how secure OH is made to be there should always be a remote proxy between it and the Internet, how much functionality are we willing to give up?
NOTE: I’m not arguing against any specific security measure nor am I arguing against making OH more secure over all. So far lots of great ideas have been put forth and all of these are a good thing. But “mo security is mo better” isn’t always true. There are always impacts and we need to make sure we know and understand what those impacts are.
The only way fail2ban can work is to deliver a IP address to nftables ( formerly iptables) so it can be blocked there.
This happens after the failed logon attempt(s) has been done; when fail2ban is investigating the log.
So the IP address must be in the log…
That’s what I thought and opened an issue to add it.
That is because it is the most secure way. Using the openhab cloud means that all ports are closed and if your firewall is decent you can be fully stealth and no one even knows you have a computer turned on. Telegram can be used to send video camera alerts out without opening ports. As soon as you open a port you increase the risks. Some options increase the risk more than others.
I personally think if the cloud is not enough for you (for example live video camera streams )it is best that people use an active project like piVPN https://www.pivpn.io/ with wiregaurd that works hard at making it easy and keeps on top of security updates. They have forums and documentation to help people and it frees up our devs to make openhab better at automation.
If you try to turn openhab into something else you won’t get as good a result unless someone takes on a lot of learning, responsibility and upkeep. Even then I doubt they will be as good as a dedicated project with an active team of people.
Anything we can do to reduce the amount of insecure machines on the internet that can be turned into bots used by hackers, this will benefit everyone.
That is because it is the most secure way.
That is just not fully true. A LAN also hosts several other devices (specially IoT devices that have questionable firmwares/origin) and with this setup you rely on all those to be secure. I know you can also lock those down, create VPN’s, IDS, DMZ’s VLAN’s, openHAB cloud and whatever. While all those measures reduce the risk, they also workaround the real problem and add alot of complexity (with new risks)
For example, i remember some openHAB API-endpoints providing data without any form of authentication/autorisation. This is a security issue no matter how you lock the openHAB ports down. A real solution would be to add a authentication and autorisation. Luckily openHAB dev’s really made improvement on that with version 3.0
Another example that it is not all about connectivity: Some bindings logged full configuration details (including passwords) in plain text when some error occured. While these logfiles are stored on the openHAB server and are not public available (changed in OH3) it is a security issue. The openHAB server might be used by other users, the log files might end up in backups (cloud providers) and so your secret is spreading. It is a common practice to not include secrets in logfiles. This issue has been fixed (as far as i know)
For sure with the current state, securing and locking down OH3 is the best route, for the future i hope the increasing attention for security by design is also embraced by OH dev’s.
Correct and that was the reason the openhab devs made big changes in this area for openhab V3. It was discussed on GitHub. Good to see you apprieate their hard work as do I. But lets try and keep the thread on topic, we are discussing one tiny aspect of network security. The topic is about why thousands of openhab installations are showing up in search results and some are totally unprotected with not even a basic password. Some are partly protected but since they show up in search results they are easily found and can have brute force attacks made.
The topic is about why (1) thousands of openhab installations are showing up in search results and some are totally unprotected (2) with not even a basic password. Some are partly protected but since they show up in search results they are easily found and can have brute force (3) attacks made.
Is it a problem that they are listed? Or is it a problem that they are not secured? Anyway, my best guess would be:
Tagging a system as openHAB could be based on many different ''finger prints". e.g. specific URL routes / endpoints that ontly exist in openHAB, some response layout, html names, ports etc. Only the dev’s at shodan.io could tell you where they are looking at.
Why they are unprotected greatly depends. Users that don’t care, users that don’t know in combination with OH2 (or earlier) that lack good default security. It would be nice to get some figures containing the exposed count i.r.t. OH version. Maybe that is something to learn from. As far as i know OH doesn’t have any telemetry about active installations / version / etc.
Able to brute force depends on used authentication mechanism. I use nginx with a progressive time-out, but not everyone does. I don’t know about the default OH3 settings. OH2 and earlier don’t have any at all.
I consider OpenHAB an insecure system by default as it provides no security mechanisms out of the box. and does not even support UI users to be set up.
Attacks inside the network are not new, no need to expose the port to the public.
You need to be a linux specialist to be able to protect the pi to a certain extent and the need for a reverse proxy is something weird as well.
But that is just my personal opinion.
Based on looking the at the top few results, it’s really basic. If the word appears in the response on at least one port, it’s identified as openHAB. It doesn’t have to be any smarter than that. But that also means that not all the results are in fact exposed openHAB instances. Some include “openHAB” in the SSL certificate. Others in headers returned by a reverse proxy.
There is a CLI interface to Shodan that someone could write a script to parse out based on certain criteria to get a count. It does look like a TCP hit on openHAB’s HTTP port returns an HTTP 200 OK that includes the openHAB version.
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Content-Length: 4019
Server: Jetty(9.4.20.v20190813)
openHAB:
Version: 2.5.0
Build: Release Build
The HTTPS port does not.
It looks like all those entries that returned that code have the openHAB logo next to them. Without looking at all of them it odes appear that the majority of the results are like this. The unencrypted HTTP port for openHAB exposed directly to the Internet without authentication (for all the OH 2.5 instances) and with maybe some authentication on the OH 3 instances.
It does not.
The majority of instances I’ve looked at in shodan have no authentication implemented at all. No encryption either since the HTTP port is exposed too.
While that may be a fair statement for OH 2 I don’t think that’s a fair statement for OH 3. The very fact that it supports users at all means there are some security mechanisms. The current set of security controls may not meet your standards or expectations but don’t dismiss the many many hours the maintainers have devoted to add security to OH 3 by dismissing them as nothing.
Well, I do not want to offend anyone, but there is no security (no password request) when opening the UI (BasicUI, as an example) (on my OH3).
I just open the browser in incognito mode (so no cached authentications), and the UI just opens at
servername:PortNo/basicui/app.
Also not for the equipment.
I can switch on and off any device from the openhab base screen (servername:PortNo/)
Anyway, there is a logon required for administration of the installation.
BasicUI was written for and OH 2 and is kept for backwards compatibility. However, if you turn off the Implicit User Role in MainUI, BasicUI won’t work at all unless a user logs in. With that turned off, none of the REST API is accessible without authentication. With that turned on, the Items REST API endpoints and a couple of others are available without authenticaiton.
You’re not describing administration, you are describing end use. Turning on and off a device through an Item is a user activity. You will find you can’t create a new sitemap, new Items, mess with Things, etc. without authentication as an admin user.
The purpose of the Implicit User Role is to meet some user’s requirement where they can give their local users access to control the lights and whatnot without giving them an account. But you can turn that off. One could argue whether it should be turned off by default but that doesn’t equate to no security.
I’m not saying that security in OH 3 is done and perfect and shouldn’t be changed and imrpoved. But saying there is no security at all is simply not fair.
I’m using nginx reverse proxy with client certificate authentication. Only downside is that I must install client certificate on every client I’m using. Simple and secure. I think it would be also possible to implement via openhabian?
Regards
It is implemented in openHABian.
Sorry. Didn’t know this.
Thanks for that hint! Is it just required to enter my external ipv4 (or ipv6) adress inside the search mask of shoda, or how did you check your own connection?
Yep. You should be able to find it in your modem’s admin page.
Ok, then this is a really great possibility to check the own network setup! I got no results for my ip so everything should be fine then. I will spread that tip to my friends. Thank you once again.