Home Assistant security concern

Installation Home Assistant OS
129

Great post, hope you got it in a onenote or something similar :slight_smile:

130

Just for clarification I have Hassio and samba add on with guest activated and no password on Samba, but on Home Assistant. I haven’t opened any ports myself, but do have a Google Wifi router with UPNP activated. Does this then mean I unintentionally have opened my installation for everyone looking?

131

What is/are the preferred configuration(s) if I wish to utilize Amazon Echos or Google Homes with Home Assistant? Using these devices are the primary reason I have my Home Assistant instance exposed to the internet.

I only have port 443 forwarded to HA and UPNP is disabled. Guest SMB access is disabled. I don’t use the HA Cloud service. I’d like to continue to use Google Home and Amazon Echo, but would like greater security than one password for HA.

I know enough about network security to know that I don’t know enough about network security, It seems seeing up Nginx would be preferred, but that would break the Google and Amazon integrations. Is this correct? Before integrating these services, I would only access HA via a VPN into my network.

Any advice on beefing up my security while still using Google Home and Alexa? Thanks.

132

If you use HA cloud for Google Home and Alexa there is no need to open any ports as far as I know.

1 Like
133

In theory this might be the case. But you should realize it’s not just Hassio Samba addon which could open ports. If UPnP is enabled any device or program (including mailware, etc.) could compromise the security of your network.

134

See Guide : OpenVPN Access to Home Assistant

And as @sjee has said for HA cloud and Google Assistant Cloud

and

135

Disable UPnP.

136

I would like to do that, but it seems like a Chromecast cannot work without it.

137

There is no reason for a Chromecast to need to open any ports.

138

I tried yesterday to deactivate UPnP and that seems to render the Chromecats unusable. It also seems like it in Google’s docs:

“Learn More: Router has UPnP disabled
UPnP (Universal Plug and Play), also known as multicast, allows for the discovery of UPnP enabled devices on the same Wi-Fi network.

It appears that you have UPnP disabled on your router. This makes Chromecast undiscoverable”

139

o.O

UPNP isn’t multicast…and I don’t have UPNP enabled on my router, and my Chromecasts work just fine.

140

UPnP isn’t just for “opening the ports” and UPnP discovery part of the protocol does use multicast. So depending on your network topology, you many need to have multicast enabled on the router in order for UPnP to work. Usually it is not a problem, when all devices are on the same network subnet.

141

yes, but I was referring to this inaccuracy (Google’s fault) of saying that UPnP is ALSO known as multicast…that is inaccurate

142

Thanks everyone for the explanation on the reverse proxy setup. I’ve now moved mine over to caddy.

Can anyone see any issues with the following config? (the homeassistant caddy config is pretty basic).

https://xxx.duckdns.org {
header / {
Strict-Transport-Security “max-age=31536000; includeSubdomains”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “SAMEORIGIN”
Referrer-Policy “same-origin”
}
tls …/xxx …/xxx
proxy / localhost:8123 {
websocket
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
}
}

https:// {
tls self_signed
status 403 /
}

Basically still using my own scripted Lets Encrypt certs rather than using caddy, mainly because I have my router scripted to open port 80 to HA when the cert is renewed, and then closed afterwards. Would rather not leave it permanently open for caddy. Caddy is also issuing a fake cert if users dont know my domain name and try to use IP address.

I also have caddy set to overwrite the X-Forwards-For header to the clients address to prevent faking of the clients IP address.

I am then using X-Forwards-For=true in configuration.yaml. I have tested curl with X-Forwards-For set to a fake address and it is replaced by the clients actual address. This means my fail2ban will still work.

With all of that taken into account, is it safe then to use X-Forwards-For and Trusted Networks together in HA?

143

Removing headers sent externally is definitely a step up in security. However, that’s the only thing your caddy proxy currently adds in terms of security.

Things to add to your checklist:

  • most important!! set up HA to know it’s receiving requests from a proxy. Without letting HA know that it’s getting requests from a proxy and to look for the x-forwarded header, HA will think ALL requests come from just your proxy’s IP on your network. This means both legit and abuse requests will come from that IP, and if you set up HA to block failed attempts it’ll end up blocking your legit logins as well. Or worse, outside logins will look like they’re coming from internal, since HA can no longer tell what the original IP was.

  • authentication for the proxy. Right now you’re just forwarding traffic to HA and trusting HA’s authentication system, the proxy doesn’t add any additional checks.

  • brute force protection. If HA responds with bad requests or auth multiple times, your proxy should block off the request because someone is likely trying multiple URLs to see what goes through. Might as well block it at the proxy instead of letting HA do it.

  • IP blocking. Don’t know about cauddy specifically, but you can usually set up whitelists on proxies easily to only allow access from your country. This vastly reduces the number of Russia/China/India etc attempts that have zero reason to be able to contact your IP at all.

1 Like
144

On point one, is that not what ‘X-Forwards-For=true’ in the HA config file does or have I missed something?

I’ll look into points 2 and 4, sounds good. Point 3, I have fail2ban reading HA’s log files and then adding a drop rule to iptables. HA will also message me that someone has been banned.

Thanks :slight_smile:

145

Ah yes. I don’t know how I missed that line, but yes, that’s exactly what you need to do.

Now after that’s done, the last step is to TEST. Now that nearly everyone has data on their phone it’s much easier to test “external” and “internal” connections, just turn off wifi on the phone and see if HA properly asks for password when coming from the data connection instead of wifi.

146

Thanks, yep being testing as I’ve been going. Just added geoblocking in caddy.

With this setup, is it safe to use the trusted-networks for internal addressing & X-Forwards-For features together in HA again, or would something still make this insecure?

I’ve got caddy replacing the X-Forwards-For with the clients IP instead of trusting the client.

Edit: Cool exercise to get geoblocking working but it broke Google Assistant and the addresses were all over the place… world.

147

I was able to get oauth2_proxy setup with Google, but it allows any legitimate google account login through. I’m probably just missing something simple, but how do I restrict to a few specific gmail accounts? Thanks.

EDIT: I still use an API password so more of a work in progress than a gaping hole.

148

Authorized mails, you need to create such files according to the instructions.