Do you use a proxy server on your network?
So @khabi has tested my network with and without the trusted network being set and Caddy and it seems secure.
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 
10 Likes
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.
Yes, haproxy. Haproxy is setup to only listen for SSL traffic on 8123; and acts as the SSL end point. It then proxies HomeAssistant port 8123.
What about the “Trusted Network”-theory above? Is that something you used?
I’m using SMB addon @@
Maybe, I should stop using it @@
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
Are you using a “Trusted Networks” definition within your configuration?
I’m so new in HA. Can you share me how to check it?
Within your HassIO add-ons, under SMB/Samba. Look for "guest": true,
https://www.home-assistant.io/addons/samba/
the fact that you are asking tells me it is set to True
In that case, you should have useful information logged there.
I’d archive those logs, then extract everything that’s relevant to this. If you can share that somewhere then I’m sure a bunch of us can help look at them (you’ll need to hide your API key and any other sensitive data).
Thank you!
Currently, My guest setting is true. If I set it “false”, is it safe? or I should stop SMB, when I’m not using it?
Why, Why, Why, Why, Why, Why, is the default guest=true???
PLEASE someone change that NOW.
1 Like
That will be fine. Enabling (as you have) guest mode enables access to the file system without a username or password. If you’ve then also forwarded ports for it, then that’s a major problem. If you haven’t however, then you should be ok still.
1 Like
No. It goes against my 25 years in IT security to ever whitelist unrestricted access in such a way.
2 Likes
would you be willing to provide me your logs and configs (sanitized of course)
Hi - I do! I can clearly see the connection(s) that caused this. They came in to 8123 from a source IP that appears to be in Romania. Nothing funny; except for the source IP it appears like any of our valid connections inbound.
So to summarize again:
- Connection came in over HTTPS to 8123; which is the only open vector.
- The IP ban is enabled at 3 attempts. It was not tripped --> Attacker did not need to try multiple passwords.
- The failed login failed persistent notification was not tripped --> Attacker either knew PW or another way in.
- Very complex and frequently changed password so not likely to be guessed in one attempt.
I’ve now moved to VPN for all inbound access which is a PITA on the iOS devices as it eats a bit of battery but seems to be working. No access from the Internet allowed (prior was only port 8123).
I/We really need to see your configs/logs at this point. Identifying a gap or leakage point of your cred is only possible with more data.
Not posted here of course lol
@jwelter Understanding each request made over HTTPS to 8123 from that IP address will be critical to tracking this down. The default HAProxy logging config should show each individual request made by the user. You should see the frontend assets being requested, and (im assuming) the websocket connection being established. Knowing the sequence and timing of those requests will allow us to better understand exactly what steps they took.
1 Like