2.2.9 Security Enhancements?

Would it be possible for the technical details of what specifically is being changed with regards to the Security Enhancements?

enhanced security measures that disable insecure access to the hub from outside local network using port forwarding or similar means. No IOT device is meant to be accessed publicly, and our hub is no exception. Use Hubitat Remote Admin, a private VPN, or other secure means of access instead.

What was changed - ie was the source IP of the browser request for admin checked to ensure it is coming from the same network as the Hub? So as long as the router / port forwarding / VPN uses source NAT, then the hub will still allow access for administration?

Knowing the networking behaviour of the hub is important to ensure continued use and/or support issues that may occur because of these types of changes. For example, not everyone has a simple flat IP network at home, and these types of changes can break networking access to the hub in unintended ways... depending on what it is doing etc.

1 Like

Hub will accept incoming connections from private address IPs and subnets explicitly defined by using /hub/allowSubnets?123.123.123.0,124.124.124.0 endpoint. Here, query string is a comma separated list of /24 subnets. So yeah, it can accommodate more complex network setups. It's simple source IP filtering on the hub side.

4 Likes

So what's the default that's taken forward after the upgrade? If my hub is on a private network of 10.0.1.6, what is the value of /hub/allowSubnets after upgrade?

That address belongs to 10.0.0.0/8 private address space, so it should be accessible from any device with IP that starts with 10. No additional configuration needed.

Anyway this can be changed in the future so it will accept smaller prefixes? I connect via a couple vpns that are using public addresses, one is a /29 subnet the other is a /28. While the rest of that /24 should not be able to reach my internal home sunet over the vpn, it still is not the best practice to allow it

Yes... the usual "no promises on when" policy applies, but probably sooner rather than later.

Thanks, will probably end up just using remote admin for now when I'm on my oddball vpn setup..

For folks with the right network equipment, there is an alternative to the Hubitat Remote Admin Service:

Also, a reverse proxy will work for this application as well since the connection will appear to be coming from the RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 -- whatever internal IP your reverse proxy is using).

I personally have been using using Apache+mod_proxy, securing acess to the reverse proxy with client SSL certificates + a user/pass login present by the reverse proxy (ie, separate authentication layer from Hubitat).

PS: That said, I also have all of the various Hubitat subscriptions (remote admin, remote backup? I forget if they're one or separate) because I have a vested interest in making sure Hubitat is profitable. :slight_smile:

1 Like

I pay for the Hubitat Protect service on both my C7's - but having my own VPN portal means I don't need the remote service.

3 Likes

Yeah, I feel ya'. I just want to make sure the Spice continues to flow for Hubitat for as long as possible. I'm worn out from switching platforms over the years. :slight_smile:

5 Likes

Likewise, but when it comes to network security, i prefer to trust my own systems.

Luckily as an SRE manager at SaaS provider, I have access to some amazing security gurus to learn from. One of them even gave my network a health check and helped me secure my network from some security issues he found.

FWIW, this did not work for me with NGINX. I had to add the public IP I was really using to the allowed range. Not sure if it's also looking at some header, but I tried modifying or removing many of those too to no avail.

It doesn't look at the headers, I've drilled into implementation details to confirm. I'll add logging to the next iteration so it would report which IP the request comes from in the logs. That should help with troubleshooting.

2 Likes

I really do like the idea of enhancing security for the vast majority of users who plug this stuff into joe consumer router. For more complex integrations how about an advanced options disable toggle? Or even something that isn't in the UI but can be disabled with an endpoint?

That toggle (UI or not) isn't going to happen, but we're listening to feedback and will do our best to accommodate the needs of the more advanced users. What's the use scenario you have in mind?

Understood. Mostly as a troubleshooting step... working with someone in another post whose envisalink integration broke with the upgrade and it would be a simple step to eliminate a connectivity issue resulting from those changes. However, there are other troubleshooting steps we can take and the problem may be completely unrelated. (BTW I'm unable to recreate his issue in my lower environment so who knows.)

Ha! story of my life there!

2 Likes

Yeah and whatever lower environments you have can't possibly include all of the sensors and devices people use... in my case I have a nonprod hub but definitely not a nonprod alarm system so it's never 100%

@gopher.ny
Where do I run the above command to add a couple of my other IP ranges?
The reason I ask is I have multiple Vlans and I currently cannot communicate across them to the hub even though the first number of the IP range is the same on all of them.