As mentioned I do use the echo devices via the hue emulation. Also Ecobee cloud, AWS Polly for TTS, dark sky, pollen and yahoo weather. But all those are outbound only.
No weird Chinese shit devices on my home automation network; just zwave+ devices with the exception of the above mentioned services.
Duh - I am sorry everyone, I see this is a hass.io thread. I am running on a venv on ubuntu so not hass.io.
Really sorry for the hijack on the wrong platform… My bad - didn’t see it was in the hass.io area… But still be cautious with security - it seems something is going on…
So I have an idea of what may be happening for at least a few people in this thread. Without seeing the full config for the http section its hard to be sure.
What I’m guessing is that people are using the trusted_network config along with use_x_forwarded_for. If you do that with a reverse proxy, its trivial to bypass the password prompt. For example, if I set up my HA install like this:
In my case I use haproxy as my frontend, if I tell haproxy to unset that x-forward-for header and add its own (not trusting one that is already set), it secures my box right up:
So I’m bemused… does this mean we should not use a trusted network (where the trusted network is our internal network) and the use_x_forwarded_for??? I don’t use the x_forwarded - only my internal network with Caddy (a reverse proxy)
or maybe does not understand them fully. You’d think setting a trusted network would be an extra level of security and so is using a reverse proxy but using them both together seems a very bad idea!
Its totally possible to use them both at the same time if you take a little care. In haproxy you just need to set these two lines in your backend configuration:
reqidel ^X-Forwarded-For:.*
option forwardfor
In nginx I think all you need is:
proxy_set_header X-Forwarded-For $remote_addr;
I’ve never used caddy, so I’m not sure on that one. If someone doesn’t have access to an outside linux box to test it, i’m willing to test for them (you’ll just have to trust me that I won’t do anything :/) Of course don’t post your info here, but PM me it and I’ll take a look.
If I get some time tomorrow I’ll try to make api endpoint people can hit to test their setup against known bad configs. I’ll toss the code for it up on gitlab/github as well so people can self host it if they want to test
The trusted networks part was my initial thought as well, I never used it myself as I do not trust anything and want the password prompt on my network no matter where the traffic comes from or it thinks it comes from.
Can you check to see if you happen to have guest access turned on and if smb is exposed through your firewall? If so, it sounds like that may be the problem