Even with my VPN setup I am still able to use the Google Assistant plugin through Homeassistant.
In addition I still have local (physical) switches, so in the case Homeassistant goes down I am still able to use my lights (no app support, but don’t care)
It’s not a plugin it’s a component and is not the same - different use case.
You can put HA behind a reverse proxy that is able to use 2FA. It not trivial, thus I only provided only a link.
In my case I use nginx as reverse proxy. @blakeblackshear provided his setup, haven’t looked into it but it should be a good start to look into.
My setup is a little more complex than running hass.io and a few plugins, but if you are familiar with docker, compose, and a typical web infrastructure stack, everything you need to know is in my config. I agree with the sentiment of a few others here and don’t like relying on homeassistant to get authentication and authorization right. Bitly’s oauth2_proxy is widely used and we use it at work to secure internal applications. It has one job and lots of professional eyes on it watching for bugs. My company pays almost $20k a year to hire security researchers to try and hack our web facing applications. This proxy is in scope as a part of that testing.
In addition, my oauth2_proxy sets a cookie at the root domain, and I run HA at a subdomain. Partly to avoid the aggressive caching of the homeassistant web app, but also because I want single sign on across everything I expose externally.
No setup is perfect. I’m sure at some point I will make a mistake and expose my stuff accidentally even though I do this stuff for a living. I implement it because I already know how and I can do it in my sleep, not because I’m terrified that someone might gain access and turn my lights on and off. When my stuff gets hacked, I will fix my config, learn from it and move on. My house is a small target with very little to gain by getting access. I’m just not that worried about it.
3 Likes
You don’t need X-Real-IP or X-Forwarded-Proto with HA. It only knows to look at X-Forwarded-For. I’d change $proxy_add_x_forwarded_for to just
proxy_set_header X-Forwarded-For $remote_addr;
so that NGinX only adds the remote IP rather than daisy chaining any received forwarded headers with it (which is obviously dangerous!!) I’ve not used NGinX for proxying in a long time, but that’s what I think the difference between $remote_addr and $proxy_add_x_forwarded_for is.
NGinX can do both basic auth and geoIP blocking on its own, see here:
2 Likes
There are a lot of useful comments in here. How can we summarise this in to something usable for the community?
3 Likes
Thank you, and thanks OP. This was the last push I needed to finally harden my HA security. I am now using oauth2, works really well, even runs Dockerized.
1 Like
What about using Dataplicity for remote access without port forwarding? Would that be a more secure way of enabling services such as the iOS app, Google Assistant, and IFTTT?
This is exactly what happened to me a month or so ago. I had at some point turned trusted_networks on and then subsequently setup a reverse proxy. DOH!
I also only ever access HA via VPN when I’m not home. Many routers (like mine) have integrated VPN support and are straight forward to setup and use, if you are not able to setup your own VPN server etc
1 Like
Please share how you set up 2FA!
I get this in the Server HTTP response header
Python/3.6 aiohttp/3.3.2yes? not sure what you’re eluding to?
Was this in regards to the aiohttp post from previous? if so, Paulus points out aiohttp-session isn’t utilized…
Hi, very intersting thread. Not great at security myself, but Shodan showed my MQTT port 1883 to be open, as well as Hassio port 8123. I reinstaled Hassio after starting to use Nabu Casa a while back and have not been thinking of the port forwarding rules that I created with DuckDNS, these have just lingered as a leftover from previous adventures. With Nabu Casa (as I have understood it) you dont need SSL certs, so for all add-ons SSL is set to false, something that is not a great combination (I think, sorry if Im wrong, still learning…). If anyone else have gone down the same route, I would guess (someone more knowledgable than me should ellaborate here), this might be worth checkig.
Please correct me if Im wrong in my assumptions.
It all boils down to how paranoid you wanna be. 
I for one have setup my home quiet tight. I run a VPN for any external connections from outside to my home. My home network is divided into separate vlans all firewalled so I can control all devices of what they can send and receive. As well as to the internet as to other devices on my network. Only one device has to get mallware to infect or sniff other local vurnabilities, so that is why I choose this route. And for that reason I also use ssl on local devices.
But to keep it simple and not as insane as my setup I would start by closing those ports on your router. Never let others use your wifi accept your own family. Maybe shield off everything from phone connections. So only connect through nabu casa (even when your at home). I know not totally local anymore, but phones are very often prone to get mallware these days.
Hope that helpes something.
Why do you have 1883 forwarded?
Likely MQTT server for owntracks.
Correct @firstof9 but Owntracks not needed any longer with the “new” Android app and locatioon included there.
I would have liiked to separate it into different vlans @frits1980 , but my router does not accept that and I have TV over internett from my ISP, so I have to use my more advanced router as an AP., otherwise Ill just end up wit an DHCP conflict. Havent tried to run my router on a different subnet, might be a solution to look into, but not got the time to look into it yet.
The answer is to stop the forwarding! This is NOT a security concern caused by HA, it is caused by you forwarding a port. Plain and simple.
4 Likes