Security - serious question (not trolling)

[klogg]

1. I am hoping for some reasoned answers / opinions here. I have no axe to grind and nor do I distrust Nabu Casa or the HA dev team. I am not trolling anyone.
2. I am an ex-IT professional who is well versed in security issues albeit at a high level as that is not my field. I am no expert in this area.
3. I am also well versed in the obvious (and fair) answers which will turn the answer back to me and my perception, aversity and exposure to risk. That is not the point of my question and nor am I looking for advice.

So…

Given that bad actors are prone to be attracted to bigger targets, should we be concerned that as HA and hence Nabu Casa grow that it might start to appear on their radar as a target worth probing?

‘The bigger the target the bigger prize’.

Reasoned answers only please, I know this can be a sensitive subject, I’m not trying to ruffle any feathers or wind anyone up.

[tmjpugh]

@klogg

Given that bad actors are prone to be attracted to bigger targets, should we be concerned that as HA and hence Nabu Casa grow that it might start to

Yes but…

Nabu casa is separate and optional to each HA install

If open your HA instance to remote access beware.

If access to HA server and my light switches is all they get who cares. Hoping for no remote execution that jumps outside docker but that’s a lot of hoops to jump and why a good backup/restore should be the end plan as you may already know

[123 (Taras)]

It’s a valid concern. Although , as mentioned, it’s not limited to access though Nabu Casa but through whatever other means one might be employing to expose Home Assistant to external access.

Whereas amateurs might be interested in the cheap amusement of fooling around with your automated devices and cameras (and what the cameras see), the pros are probably more interested in gaining access to the machine itself so they can leverage it to become part of a botnet and/or to gain access to other computers on your network (like for ransom purposes).

FWIW depending on which installation type you chose, it runs with root privileges (a practice generally frowned upon) which, if compromised, provides full access to the host machine.

[klogg]

@123

it’s not limited to access though Nabu Casa

Yes, true and it was my fault for not being more specific.

The thrust of my ‘concern’ was access via Nabu Casa because it is, for want of a better phrase, ‘a complete black box consumer orientated service’ (please don’t nit-pick my choice of words, hopefully you get what I mean).

If you decide to take the ‘diy’ approach to opening up your network then this…

@klogg

I am also well versed in the obvious (and fair) answers which will turn the answer back to me and my perception, aversity and exposure to risk.

…is especially relevant:

[Burningstone]

@klogg

complete black box consumer orientated service

I’m not sure if I understand you correctly, but the code is available on GitHub → Nabu Casa, Inc. · GitHub
so it’s no blackbox.

[klogg]

Yes, bad choice of words… I mean it is ‘a box’ i.e. no need for the average ‘consumer’ to do anything other than follow the instructions. And being a ‘service’ no one should be expected to and nor could 99% of users read the code and do any serious checks. That is a niche area of expertise that even the experts can’t always get right.

Being on GitHub is no indicator of the impenetrability (or quality, or of anything really. Except that I can read and change the code if I want).

[Burningstone]

Ok, then I agree blackbox for me sounds like you can’t find out what’s “inside” because the owner keeps it proprietary.

@klogg

Being on GitHub is no indicator of the impenetrability (or quality, or of anything really. Except that I can read and change the code if I want).

Totally agree, however it has been shown that generally open source security code tends to be less vulnerable than proprietary code.

[Tinkerer (aka DubhAd on GitHub)]

@klogg

Given that bad actors are prone to be attracted to bigger targets, should we be concerned that as HA and hence Nabu Casa grow that it might start to appear on their radar as a target worth probing?

Yes

Pragmatically though, Nabu Casa’s user base is still pretty small. There’s many more interesting targets out there (like Mosquitto, or your modem/router, or …).

That’s not to say somebody won’t take the code apart and find something, or one of the upstream libraries used won’t have a security issue that doesn’t impact it.

It’s a risk, sure. But so is using something like Tuya’s cloud services, or Xiaomi’s, or … There’s nothing special about Nabu Casa here.

[nickrout]

If bad actors get hold of my nabu casa account (or other secured HA access) then it is not so much the “in the cheap amusement of fooling around with your automated devices and cameras (and what the cameras see)” (as @123 ably put it) nor is it really being botnetted (although that is bad), but probably access to my passwords and to my locks/garage doors and physical security shit like that.

But yes, of course nabu casa is a target for someone. Aren’t we all?

[koying (Chris B)]

Nabu Casa is probably the most secure way to expose HA to the internet.

Imho, the biggest risk is for the people opening up via the nginx / duckdns addon without really knowing what they do nor the risks…

[Stiltjack]

@koying

Imho, the biggest risk is for the people opening up via the nginx / duckdns addon without really knowing what they do nor the risks…

OK, I’ll hold my hand up, that’s me.

I have the duckdns addon, in configuration.yaml I have:

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

…even though it makes it difficult to use the HA app, and I have two-factor authentication enabled. What else should I be doing?

[Tinkerer (aka DubhAd on GitHub)]

Assuming you’ve worked through this, then there’s only a few other easy things to do:

1. Use a reverse proxy server for SSL. Using a proxy server allows you to do filtering there, rewrite requests, limit access, and more. You can take this up another level by using one with WAF (web application firewall) capabilities.
2. Don’t use port 443 or 8123, or another common port. No, this isn’t security, but if you pick a random high numbered port it cuts down on the number of people that will find it. It’s hard to pick a lock you can’t find.
3. Deploy the likes of fail2ban on your proxy server
4. Consider only permitting remote access to the bits you need - I use my proxy server to only allow remote access to webhooks. If I want remote access to the UI I’ll just use my VPN, which brings me to…
5. Use a VPN for remote access to the UI
6. Keep an eye on the proxy logs for signs anybody has found your server and is attempting to compromise it

[Stiltjack]

On it, thanks.

[koying (Chris B)]

@Tinkerer

Don’t use port 443 or 8123, or another common port

Similarly, I have also configured my remote proxy to only forward a specific FQDN to HA.

[srkoster]

How did you configure your proxy server to only permit access to your webhooks? Id love to restrict remote access to the HA location tracker API with my Nginx Proxy Manager.

[Tinkerer (aka DubhAd on GitHub)]

For NGINX it’s a default deny, with only some things permitted.

/api/webhook
/api/websocket

	location /api/webhook {
		allow all;
		include conf.d/proxy.conf;
		proxy_pass http://127.0.0.1:8123;
		proxy_set_header Host $host;
		proxy_http_version 1.1;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_ignore_client_abort on;
	}

	location /api/websocket {
		allow all;
		include conf.d/proxy.conf;
		proxy_pass http://127.0.0.1:8123;
		proxy_set_header Host $host;
		proxy_http_version 1.1;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_ignore_client_abort on;
	}

	location / {
		satisfy any;
		deny all;
	}

[vistalba]

Found this thread because of the security vulnerability thread which has a link to this.

Unfortunately this does not cover everything when I look on my iOS app. Does this really work for you?

/api/webhook
/api/websocket
/api/ios/config
/?external_auth=1
/manifest.json
/local
/api/hassio

The problem I now facing in is that /?external_auth=1 is the path / basicly. Any idea how to cover this?

[Tinkerer (aka DubhAd on GitHub)]

I don’t use the iOS app, can’t talk about what that needs, or doesn’t need.

I also don’t use anything Supervised.

I also don’t use the UI remotely.

Just the two I listed are enough for the Android app to report to HA for me.

[srkoster]

Are you planning on using the UI of the iOS app outside of your home? Tinkerer’s approach is to use a VPN in that case.

Or do you only want to send location / sensor updates through your reverse proxy back to HA? In that case, I’ve seen that /auth/token should also be added as a location to keep the connection alive. On my Android phone /api/webhook and /api/websocket seem to be enough. However, on my wife’s iPhone somehow the app tries to refresh the token after about 30 minutes after leaving the house (which fails with auth/token blocked). Then the app logs here out and she needs to logging again.

I don’t see any calls to /auth/token from my Android app, except when I try to use the UI.