Just noticed in docs that Samba guest is default “true”.
Would default “false” be better since many upnp router?
1 Like
I think that would be a safer choice. If they’re using SMB, theres a good chance they’re not that versed in sysadmin/security concepts or administration to begin with. This would lead me to believe they’re likely to have UPNP on either from factory, or would have inadvertently turned it on for something like Xbox live or the like.
Thanks for this.
As I stated only HTTPS to 8123 is enabled. No SSH or SMB enabled from the internet. A port-scan confirms this. Also the HA box sits on it’s own private network with nothing else present except the ecobee’s, Echo’s, etc. Basically a home automation network. No remote access or VPN to this network from outside.
From my home network I only allow HTTPS on 8123 and SSH on 22 onto the private home automation network.
So I’m pretty secure. Lots of log reviews confirms that whomever did this came in on 8123. I see it in the logs.
I’ve tested the IP ban for wrong passwords and it works; and I also get a persistent warning in the HA web GUI. So whoever came in knew the password as they didn’t fumble around guessing.
The only way I could be more secure is to enforce the IOS remote app to come in on 8123 over VPN so it’s not publicly accessible… That is a PITA but Mayne needed.
He also seems to have MQTT port open - was that with username/password?
Do you use public WLANs?
But is the addon enabled?
are you using the cloud integration of HA? (Alexa, etc)
No cloud via their cloud service.
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…
Yes, I use cloud to integrate with Alexa.
It shouldn’t matter how open your samba server is if you don’t expose it to the internet.
1 Like
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:
http:
server_port: 8080
api_password: !secret hass_password
use_x_forwarded_for: True
#My internal network is 10.0.0.*
trusted_networks:
- 10.0.0.0/16
ip_ban_enabled: True
login_attempts_threshold: 5
I can test it from outside my home network and it looks secure.
root@myhost:~# curl https://my_public_url_goes_here/api/
401: Unauthorized
But I can break it very easily:
root@myhost:~# curl --header “X-Forwarded-For: 10.0.0.1” https://my_public_url_goes_here/api/
{“message”: “API running.”}
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:
root@myhost:~# curl --header “X-Forwarded-For: 10.0.0.1” https://my_public_url_goes_here/api/
401: Unauthorized
If you have access to an external linux box, I highly suggest you test that out to see if it works.
2 Likes
interesting there’s a thread about this
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)
The docs here https://www.home-assistant.io/components/http/ seem to say it maybe shouldn’t be used…
Yes of course, but no one reads the docs.
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!
1 Like
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.
This seems to indicate it’s handled anyway by default
What details would you need? I’ll play…
I just need to know what you have for trusted_networks, and the public url to your instance.
1 Like