Professional Remote Access for Your Smart Home. Part 4
Previous part: Professional Remote Access for Your Smart Home. Part 3
To install it on Windows just click the link and run the file. Windows comes with a Proxy Manager application which is just a text editor with a couple of extra buttons to validate the file and start the service. You can also just edit the config file directly in the "conf" subfolder of Duo's installation folder. Just like with FreeRADIUS, the configuration is all done in the text file; regardless of whether using Windows or Linux. Speaking of Linux... we've already got FreeRADIUS and openHAB installed on the Linux machine, so let's drop Duo on there as well. I just need to copy-paste the lines form my distro from Duo's documentation. I do have SELinux enabled, because for once in this video I'm actually adhering to good practice; so I'll need to copy a few extra lines to make that play nicely with Duo. It's supposed to do all of this, by the way; and it will take a little while. Rather than coming as a pre-packaged binary we're actually building it from source.
Compiling the code yourself might sound a little scary but all you're doing is copy- pasting a few commands from the documentation. It'll ask you a bunch of questions. If you followed the steps in the documentation then you can just press Enter to accept the default answers. Now it's installed, and just like with Windows we configure it by editing a text file - the location of which it handily gives you at the end of the installation script. The contents are exactly the same as the Windows one. We want to delete all of the example text that's in there already. There are two sections we need to add. The first is a client section. This tells Duo how to talk to FreeRADIUS. The second is the server section. This tells Duo how to talk to Kemp. Let's create a RADIUS client to talk to FreeRADIUS first. FreeRADIUS is installed on the same machine and we left it with a default configuration to talk on the loopback address, so our host IP address is 127.0.0.1. We left the default secret of "testing123".
Read about: Ryzen 5 5600X vs 3600
That's all we need to talk to FreeRADIUS, now for the server section. First we'll reference our client section so it knows to proxy Kemp to FreeRADIUS. Your integration key, secret key, and API hostname can all be copy-pasted from the openHAB RADIUS application we created in Duo's online portal. Take note of the information in the documentation about how to encrypt passwords. For the sake of time I won't bother but you really should store the secret key and the RADIUS secrets in encrypted form rather than cleartext. The RADIUS IP is the IP address of the Kemp LoadMaster. By default this will be the IP address we used to manage it and not the IP address of the virtual service we created.
The RADIUS secret is the password Kemp will authenticate with. Again, when you do this you should pick a better password and encrypt it. If we don't add a property for the port number, Duo will listen on the standard RADIUS port: 1812. That's going to be a problem for us because FreeRADIUS is also installed in the same machine and it also wants to listen on port 1812. To avoid a conflict I'll tell Duo to listen on port 1814 instead. The last setting I'll change is the second factor type. By default it will allow several methods but I'm going to Hard code it to use push notifications.
Check also: Lenovo Legion 5 vs HP Omen 15
The reason for doing this is because a) it's my preference and b) on the free plan we get some credits for phone calls and text messages, but once they run out we need to buy more. The push notifications are free so I'm going to force that type. That's it. Save our file and start the service. You can start it via systemd using systemctl. The service name is auoauthproxy. But you can also use this auth proxycontrolctl command which will spit out more information if you messed up the config. If it does spit out any problems you can use the authproxy_connectivity_tool to validate your configuration and network connectivity.
The last thing before we leave our Linux server is we'll need to open the firewall so Kemp can talk to it. In our last video we opened port 8080 because that's the default HTTP port for openHAB. I'm actually going to close that now and open 8443 instead, which is default HTTPS port for openHAB. This is a little more secure - especially if you put Kemp in a DMZ. I'll also open our Duo RADIUS port 1814. Note this one is UDP, not TCP. Teload our firewall rules and Linux is ready. Back to Kemp. To get Kemp talking to this we head to "Virtual Services" and "Manage SSO".
SSO being short for single sign-on. Add a new client-side configuration. We'll call it Duo. The authentication protocol is of course RADIUS. Our server is the Linux openHAB server, but because we're using a non-standard port we need to specify it by putting ":1814" after the address. The secret is the one from the server section of our Duo config. We can leave the rest as-is apart from the RADIUS login format. "Principalname" expects something that looks like an email address, but we're just using a plain username.
Read about: Ryzen 9 5950X vs 3950X
OK. Kemp can talk to Duo and Duo can talk to FreeRADIUS. Let's enable the authentication. Back in the openHAB virtual service we're looking for "ESP Options". ESP is "Edge Security Pack", not "Extra Sensory Perception". This is where Kemp does its authentication. "Enable ESP", and suddenly we have a bunch of options. "Client Authentication Mode" will be "Form Based". The "SSO Domain" is the "Duo" one we just created. Ender "Allowed Virtual Hosts" we put the DNS name that we're publishing openHAB on. In my case that's openhab.protechshow.com.
For "Allowed Virtual Directories" I'll put "/*" which means "everything"; and the only other tweak I'll make is to turn off the "Public/Private Option" because we don't care about that. That's the authentication enabled. It's now officially safe to connect this to openHAB. We do this under "Real Servers" set the "Check Method" to HTTPS because that's what we've allowed through the Linux firewall, and click "Add New". Now we give it the address of our openHAB server, change the port to 8443, and click "Add this Real Server". Go back to your list of virtual services and if you've done everything correctly the openHAB virtual service should have a green tick. If it doesn't, this means Kemp can't talk to openHAB.
Double-check openHAB is running, you've opened port 8443 through the firewall, and you didn't typo anything. All's left is to try this out, then! If I browse to openhab.protechshow.com I get a Kemp-branded login screen. You can redesign the screen any way you want if you're comfortable with HTML. Kemp has documentation on how to do this. The logon form is protecting access to openHAB. To get past it I need to type the username and password I configured in FreeRADIUS. If I did that correctly I'll get a prompt on my phone to approve the login. Once I've approved the login I'm through to openHAB having improved my identity in two different ways: something I know by entering my password, and something I have by responding to the prompt on my phone.
Read more: GTX 1650 vs 1650 Ti
Let's be honest: that password I used is going to get breached pretty quickly, but even so nobody's getting access to openHAB without both my password and my phone. If you liked that, like the video. Because of YouTube; and because it helps motivate me to make others. One way we can tighten up security further is by enabling Kemp's web application firewall. You'll find this in the virtual service under WAF. There are actually two of them.
The standard WAF is not included in the free license, I'm afraid; but the legacy one is. It's older and clunkier, but it's free. If we expand that you'll see a warning saying there are no more legacy WAF rules. If we enable it there's nothing here, but that's not going to stop us! If we head to "Web Application Firewall" and "Custom Rules" we can add our own. Where can we get these you might ask? Go to coreruleset.org to find the OWASP ModSecurity Core Rule Set.
This is a set of web application firewall rules that cover some of the most common web-based attacks. They're free and they're compatible with Kemp's legacy WAF; so we can download these rules, import them into Kemp, and go assign them to the WAF in our virtual service. What this will do is it will enable Kemp to inspect the inbound connections to see if anything in the connection matches one of these rules. If it does, Kemp will block it to prevent the attack reaching openHAB. This is a topic that will need another video because WAFs are not quite plug and play.
There's a lot of tweaking required to get it tuned correctly. For example if you look at some of the attacks that ModSecurity works for, Java code injection is one of them. Ordinarily if a WAF sees you sending java code to a website it's going to think that looks dodgy and will block your connection; but consider openHAB's automation rules. They can be written in Java. Transmitting custom Java code to openHAB is one of the ways you can configure your automation. For openHAB it's a legitimate use case, but for most other websites it looks like an attack.
There's a lot of nuance like this with web application firewalls so drop a comment if you want a video on it. One last thing that might be handy to do is to set up an additional IP address on Kemp that bypasses the authentication. That way you can have your public IP address pointed at the secure service, and internally within your house you can use the trusted one. To do this we can select the existing virtual service and click "Duplicate VIP". Give it a new IP address and call it "openHAB Internal", then scroll down to "ESP Options" and turn it off. You'll probably want another HTTP redirect, and you don't need the WAF on this one. To make use of this you use a technique called split DNS. Externally, your DNS name resolves to your public IP address, which is mapped to your secure virtual service.
Read about: What is Saber (SBR)?
Internally, you create a different DNS record that resolves to your internal virtual service. This way you have multi-factor authentication for remote access, immediate access when at home, and both use the Let's Encrypt certificate to avoid security warnings. We are so nearly done now but I still need to tell you why I didn't just use Cloudflare. One of the reasons was just that I think you learn more about building it yourself, and one of the goals of this channel is education. The other is that I've done all of this to avoid using the openHAB cloud service for remote access because it uses weak single factor authentication; but the myopenHAB.org service does more than remote access. It also provides a really easy way to integrate with the Amazon Echo and Google voice assistants and smart home ecosystems.
You can do this yourself but it's a pain. You need more servers. You need to set up OAuth authentication. You need developer accounts. You have to register apps with them ,and link it all together. Or you can just click a button and it's all done for you by the myopenHAB cloud service. That is really cool... and I use it, but I can't use it as-is because it brings me to the second issue I have with the service. It does not adequately adhere to the principle of least privilege. In order to grant Google access to switch on a single light bulb I need to give myopenHAB.org full remove access to every part of my openHAB server; and by inference I am granting access to my home network. I will not do that.
That backdoors all of the work I've done so far and exposes my entire network behind some flimsy password authentication. Cloudfare could give us remote access but it will not solve this problem. The infrastructure we've just built, however; can. Believe it or not we can use this to add a layer of security to the cloud service and force it to obey our own rules of least privilege; and I'm going to show you how we can do that in this video here, so you can easily integrate with supported cloud services without backdooring your entire network.