Professional Remote Access for Your Smart Home. Part 1
In this article we're taking lessons from enterprise IT and we're using them to build our own secure remote access for our smart home controls. You can apply this to anything, of course. The specific example i'm using is openHAB, but you know... corporate intranet, CRM system, home media server... why not?
You might be tempted to just open a firewall port through to openHAB and be done with it. Don'!t openHAB 's password protection is more of a child lock than a real security mechanism. By that I mean it stops people messing with the configuration but it doesn't stop them actually using the system. Say you have a camera and a thermostat hooked up.
The built-in password would prevent a random person on the internet from adding a new heating zone or changing the camera's polling interval; but without logging in they could still access it and crank up the heating and literally watch you sweat in your own home using the camera. Not good! So we need an additional security layer in front of openHAB, and openHAB comes with three suggested options to choose from.
Addressing the elephant in the room, openHAB has a companion cloud service called openHAB Cloud; and there's a free instance you can use at myopenHAB.org. And when I say "free" I don't mean "Facebook free" where you pay with your data. It's just free. It's provided at no cost and is maintained by volunteers. I can't in good faith recommend it to you in its current form but that doesn't mean I don't greatly appreciate all of the hard work by people who ask for nothing in return.
They are awesome, so please do not take this video as a dig at them, but there are a couple of weaknesses in the current openHAB cloud service that for me are deal-breakers. The one this video is concerned with is authentication. myopenHAB.org uses weak single-factor authentication. In short, a password. But wait... doesn't most of the internet work like that? Well, no. It used to but you've probably noticed most websites these days are either offering or pushing you into using multi-factor authentication. That's because passwords simply aren't safe anymore. Think about it.
Computers can guess at rate of millions of passwords per second, and they get faster every year. We make passwords more complex to counter this, but this just guarantees that as time goes on they're getting easier for computers to crack and harder for us to remember. The way they function doesn't make any sense, either. Using a password on the internet means transmitting your password to the website. Modern authentication methods don't do that. They send proof of your key, not the actual key itself. If the internet was designed today passwords would not be allowed; and if I were to deploy a system that relied entirely on passwords at my job I would probably be facing a disciplinary.
The other two options openHAB suggests are using a VPN or setting up a reverse proxy using Nginx. VPNs can be overrated. You don't have to expose your app to the internet but you do have to expose the YPN instead; and if the VPN gets breached it probably grants access to your entire network instead of just openHAB. There's nothing wrong with a VPN if it's using strong encryption and strong authentication. If you're publishing multiple apps there is an argument that exposing one VPN is more secure because it reduces your overall attack surface; but if your VPN is PPTP-based or relies on a password... you'd be safer using myopenHAB.org.
The final option of using Nginx is architecturally similar to what I'm going to do, but as-is you've still got the issue of weak authentication. You could build out Nginx and hook in additional services to solve this, but I'm going to use something else instead. For my reverse-proxy I'm going to use a Kemp LoadMaster. These are commonly used in businesses as load balancers but they have additional security features beyond just load balancing.
The interesting thing for us is that Kemp have a free version. It's bandwidth-limited and can't be clustered, but none of this matters for our use case. We're not running a datacentre and openHAB doesn't need a lot of bandwidth, so the free version is fine. Instead of punting firewall ports through to openHAB we're going to punt them through to Kemp and let it handle the security. It's our bodyguard at the door. There's a never-ending scale of security we could apply, but we have limited time so I'm going to show you what I consider to be the bare minimum; however, I will also point out improvements that you should consider as we go. I can't cover them in detail here but leave a comment if you want a video about any of them.
Read also: Razer Blade 15 benchmarks
The first of these recommendations for improvement is that instead of simply dropping Kemp into the same network you should ideally put it in a DMZ or perimeter network. This provides an extra layer to your security because KEMP is the thing we're exposing to a potential attack. Unlike openHAB it's designed for that; but because it's the target putting it in a different network means if someone breaches the first line of defence they still haven't made it into your main network. There are multiple ways of setting up a DMZ. Comment if that's a video you're interested in. We'll also need something to validate our credentials. Kemp is the security guard that asks for your ID, but it doesn't issue your ID.
For that we need an identity provider. Kemp supports many standard authentication protocols. LDAP, Active Directory, RADIUS, OIDC, SAML, certificates, etc. Deciding which to use is pretty straightforward if you already have an identity provider: use that one! If you use Microsoft 365 or Google Workspace for example, just use that. Make sure multi-factor authentication is enabled and call it a day. If you use Active Directory or RADIUS though and it's single factor you'll need to add an additional authentication step to make it secure. For the purpose of this demo we're going to deploy FreeRADIUS, and then we'll beef that up with Duo to give us multi-factor authentication. We'll be using DUO's free plan which is good for up to 10 users. So overall what is this going to look like, and what do we need to make it happen?
Next part: Professional Remote Access for Your Smart Home. Part2