I agree with Markus and Hans-Jörg that you are probably going about this from the wrong angle. But I’d like to explain a little bit more about why and how to circle around so you can find the right angle.
Consider the following formulas:
Risk = Likelihood * Impact
Likelihood = Chance vulnerability exists * Chance that a threat will exploit it
Impact is a number, often in terms of money, that represents how much it will cost you if the you are successfully attacked.
Obviously these formulas are not strictly quantitative but they help one think about the problem.
OK, so we have your root concern: an attacker blocks access to OH for other openHAB users.
How can the attacker do this? Here is where you need to brain storm and come up with all the ways that an attacker might do this. These are called the vulnerabilities. They might cut the power, jam the wifi, and so on.
Now here is where you’ve turned wrong.
-
Any way that an attacker could do this that requires physical access to the machine running OH means you’ve already lost (they can just unplug and smash the machine).
-
Any way that attacker can do this that requires root access to the machine itself means you’ve already lost (they can just systemctl stop openhab).
-
Any way that requires the attacker to have access to your LAN means you’ve probably got bigger problems than whether they deny your openHAB users access to openHAB which you should focus on mitigating instead.
NOTE: An attacker need not be human, which is why it’s often called a threat. Threats can include weather, fire, ants, etc.
Now you’ve iterated over the reasonable vulnerabilities pair those vulnerabilities with threats. In this case you are concerned about some nameless attacker exploiting a vulnerability to deny access to your openHAB users. How likely is that to occur? If you are someone who is of interest to a state actor it might actually be quite high. For most people, it will be quite low.
Now back to the risk calculation.
Come up with some number to represent the impact should your users lose access to OH. Now multiply it by the likelihood that an attacker will actually do that. Anything that you do to mitigate this risk should cost less than the risk.
So if the impact is $1000 and the likelihood is 5%, anything I do to mitigate that risk must cost less than $50. So remember that your time has value and anything that you do to mitigate the risk can impose opportunity costs as well.
Use these sorts of exercises to help you identify the big risks and focus your efforts on those. If you are running an OH system on a LAN that is not directly exposed to the internet, your time and effort is much better spent making sure your LAN is secure and your machine has backup power and stuff like that. Maybe spend a little bit of effort on locking down the network on your OH machine so only certain IPs even on the LAN can communicate with it. Lock down SSH so it requires a cert or both a cert and password to log in. That is the sort of thing that is worth doing. Doing integrity checks on the OH users file doesn’t actually mitigate anything. By the time the attacker can get to that file, they can achieve their goals in so many more effective and destructive ways.
In short, the mitigation costs way more than the risk.
