Hardening openHAB Linux system (Ubuntu, openHABian)

Tutorials & Examples
1

I’m running openHUB (openHABian) on an Intel NUC. I’d like to harden Ubuntu as much as necessary, as little as possible. To be honest I don’t want to create a “Fort Knox” but a minimum level of security.

Let’s summarize here some some steps for hardening Ubuntu (or Linux in general).

Use strong non-default passwords

Change user password (e.g. for user openhabian):

passwd

Change root password

sudo passwd

By default root does not have a password and the root account is locked until you give it a password. So there’s no need to change root password.

change samba password for openhabian

sudo smbpasswd openhabian

Password for Karaf remote console (e.g. “openhab:habopen”):
The password is stored in the file users.properties, located in the etc directory:
→ http://docs.openhab.org/administration/console.html#changing-the-password

This password can also be easily changed via the openHABian menu

sudo openhabian-config

→ 30 System Settings → 34 change passwords

Disk encryption

This option can easily be acivated (encrypted LVM) but is not recommended for a dedicated openHUB server:

  • normally there’s no sensitive data on a dedicated home automation server
  • manual steps are needed for booting/rebooting

Security updates

Every server needs software packages to fulfill its destiny during the lifetime of the system. Ensure that it gets regularly patched and updated.

In general there are two strategies:

  1. Do it manually to have full control: Make a habit of checking for updates on a regular basis
  2. Activate automatic updates. You lose somewhat control of your system but this guarantees an absolutely up-to-date system

Ubuntu Desktop
There’s a dedicated menu for updates:
→ Software & Updates

BTW: Does Ubuntu Desktop reboot automatically if needed? Where can Automatic-Reboot-Time be set (e.g. “02:00”)?

Ubuntu Server
Install package

sudo apt install unattended-upgrades

Edit the following file:

/etc/apt/apt.conf.d/50unattended-upgrades

Is there any suggested setting? In my opinion we should focus here on security updates only, right?
→ “${distro_id}:${distro_codename}-security”;

activate automatic reboots:
→ Unattended-Upgrade::Automatic-Reboot-Time “02:00”;

Firewall / IP address blocking

Fail2ban

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs – too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, courier, ssh, etc).
Fail2Ban is able to reduce the rate of incorrect authentications attempts however it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services.

SSH keys

UFW - Uncomplicated FireWall

Easier administration of linux

Webmin

Webmin is a web-based interface for system administration for Unix. Using any modern web browser, you can setup user accounts, Apache, DNS, file sharing and much more. Webmin removes the need to manually edit Unix configuration files like /etc/passwd, and lets you manage a system from the console or remotely. See the standard modules page for a list of all the functions built into Webmin.

Think big, start small

Other points?

Is there any other point to be watched?

Links

https://help.ubuntu.com/lts/serverguide/automatic-updates.html

Next steps

Please feel free to share your opinions and “best practices”. I’ll then update the above guide. Thnk you very much in advance.

2 Likes
2

Fail2ban: very simple & easy to use and highly effective.
(optional) Webmin for easier administration of system (and firewall) (maybe it’s too “heavy” for smaller systems)

No for disk encryption, yes for ssh keys.

1 Like
3
4

In general, I would not use encryption for a server like this. In a power outage you want this server to come back up auto automatically and not require one to enter a password. Even worse, you likely want this machine to run headless meaning you would have to bring a monitor, keyboard, and mouse or a laptop and serial to USB cable to the machine to get it to boot up. Yuck.

Personally, I like to do updates manually so I know whether it was an update that hosed my system in some way or something I did. I wrote some Ansible playbooks that will update all my servers at once and I run it once a week.

Also, automatic apt-get updates will do nothing to address updating docker images if you happen to be using docker.

UFW is pretty easy to set up, easier at least than IPTABLES. You will want to allow SSH incoming and HTTP and HTTPS outgoing or else apt-get won’t be able to download updates. What else you allow will depend on what you are running. If you are running OH you will need to allow ports 8080 and 5000 at a minimum.

I would recommend setting up SSH keys rather than a whitelist of systems. That way you don’t have to enter a password and only those systems/users who have access to the private key can log in. Once that is set up disable password ssh logins.

I’ll second @Dim’s suggestion on Fail2ban.

The only thing I’ll add to @Udo_Hartmann’s that you also need to change the listen on address to allow connections to the karaf console from anything other than localhost. If you set up the firewall you will need to add the karaf consol port as allowed as well.

Some other ideas:

  • Start with a minimal/server based distro and add those things you need and remove those things you don’t. The more you have installed and running the larger the attack surface.
  • Some disagree, but I recommend deleting the default user. On a RPi this means getting rid of the pi user and add a new user.
  • Backup backup backup.
  • Test your backups.
  • Install some sort of Host Intrusion Detection System. There are all sorts to choose from. Configure to watch those folders that should not be changing and to email you when there are file changes where there shouldn’t be.

All that being said, hardening the host is only a small part of the problem. You also need a good network security approach. Some ideas there:

  • isolate the home automation on its own LAN
  • Put a reverse proxy in a DMZ sandwitched between two firewalls with a controlled access between your reverse proxy and your servers
  • Just having a reverse proxy to add HTTPS and user authentication
  • LetsEncrpyt certs
2 Likes
5

Does this involve a second router? Or can it be done by configuring your router? I have a TrendNet router running DD-WRT and Ethernet to every room.

6

If it is running dd-wrt I’m almost possible you can do this on your existing router.

Do a little internet searching on “dd-wrt vlan” to get started. A blanket, or virtual local area network, uses tagging and sometimes encryption to allow the one router to support multiple virtual networks. Your reverse proxy will likely need access to both networks so you can reach your OH server from your day-to-day vlan.

7

Thanks, I’ll do that. Network engineering isn’t really my strong suit, but I figure a project like this would provide a great learning experience. I’m contemplating adding some IP cameras, so I’d like to enhance my network security first.

8

Thank you very much. I added your inputs to my initial post.
Is there any sample configuration or best practice for openHAB?

9

Thank you very much, your inputs are highly appreciated!
Is there any manual or best practive for setting up UFW for opnenHUB? Is UFW still needed if fail2ban is already running?

10

There is no openHAB specific instructions. There are tons of tutorials and manuals a Google search away. The only thing you need to know is the ports OH uses, which are: 8080, 8101, and 5000.

11

Is there any benefit on installing the reverse proxy (nginx or apache) with ssl certificates if the system is only going to be used locally via IP and remotely via myopenhab.org (mobile app)?

I am tempted to install it, but I am afraid (of no reasons). Just want to know if I will benefit anything :slight_smile:
I also read that for google home, port 80 needs to be free, so I would like not to occupy it and then later have to change all the devices and settings etc.

12

A standard approach to security is called defense in depth. By configuring a reverse proxy and disabling access to OH except through the reverse proxy will let you encrypt the UI traffic even while it is on your network. This makes it just that little bit harder for someone already on your network to mess with your system.

Another thing it enables is adding authentication for access to the sitemap so you can password protect the access.

You can put the reverse proxy on any not already occupied port. 80 is used because that is the default http port but you don’t have to use it.

1 Like
13

Thank you, I installed nginx using the openhabian script. It installed it ok, but since I was using the IP internally, it added “localhost” as redirection from port 80 to 433, and localhost then didn’t resolve as it is not the server IP. I changed that manually (and will open the ticket for openhabian),
I also closed all other ports with ufw firewall except for 433, which goes trough nginx reverse proxy.

And all works fine (when all is straight forward) but I still get “connection not secured”, I guess I need to manually somehow enable ssl certificate for ip locally, that could not be fixed automagically with openhabian script? (should I open a ticket for this as well, or did I miss something?) It mentioned that port needs to be open or something will fail, I guess that is what is needed for certificates?

One more thing, on the mobile app, I now have to have a same username for both local AND myopenhab.org?
on myopenhab I have two users, I guess local auth needs to be same for both now, or a combination or…?

Btw, should I open a new topic about my questions (although I think this is recommended use scenario, not opening ports to the internet)

Thank you for your help

14

The way I have hardened my OpenHABian. Have plans for further hardening and once done will also share. This is what I looked at so far:

  • Password change
  • Securing the SSH connection
  • Disable not needed interfaces (e.g. wifi and Bluetooth)
  • Configure SMTP to ensure alerts can be sent
  • Configure unattended updates
  • Backup to Google Cloud or locally on USB
  • Add fail2ban
  • Enable logwatch, incl. automated email reporting
  • Enable SSH login notification

I made all the details how I configured that on openhabian 3 available to the internet. Step by step. Looking forward for your inputs and comments. As said, I would love to add more hardening in a next phase / step

Hardening of OpenHAB Guide

Hope you like it and it helps you.