FYI: https://github.com/home-assistant/home-assistant/pull/18770 – am seeking guidance from some members who have more experience in this subsystem. Will keep everyone posted.
So this seems to work and I managed to lock myself out a few times as well (deliberately)
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
- ::100:
I’m having a similar issue where I’m seeing bans from 172.30.33.x addresses. At first I thought it was some crazy hacker and I tried to find out who it was. I’m not IT guy so I quickly found out that 172. is a private IP address. This is confusing to me as I use the 192. private IP for my network. To test that this was coming from inside, I logged out of HA and purposefully entered wrong passwords. Whether I was on the local network or from my cell phone (off the wifi) it put out the 172 ip ban. I have a feeling this is coming from using Nginx but I’m not sure how to configure it a different way. Again, I’m not an IT guy and it seems like a lot of the info I see on Nginx is for people who already know what they are doing.
In all my searching to figure out how to solve this, I came across something that said to NOT to what @DavidFW1960 is recommending as it could allow spoofing of IPs and bypassing the password entirely.
https://github.com/home-assistant/home-assistant/issues/14345
Maybe I’m reading this incorrectly or this has been fixed but thought I’d bring it up. Hopefully someone else can chime in with the latest/safest way to set use_x_forwarded_for, trusted_networks and trusted_proxies when using Nginx.
If you don’t set the use_x_forwarded_for: true then you won’t ever see the real IP address of anyone connecting. The 172 addresses BTW are docker.
If you use x_forwarded_for then the real IP address of anyone connecting is visible. and if you use that you have to use a trusted proxy. The settings I put in here are straight out of the docs for http.
Since putting that in, I get the IP address of the last connected user using the last_authenticated sensor.
I don’t find this very intuitive and if someone feels there is a security risk in the settings as I have them. Not also that in that github issue, you also need to have trusted_networks defined. (I don’t) and an API password (I don’t). So everyone has to authenticate using the new auth username and password and also enter the 2FA code from my phone. That is a very old issue from an old version of HA prior to auth. The ONLY thing I am trying to achieve is to see the authenticated IP addresses and not get banned for no good reason as per this thread. I was finding that my 127.0.0.1 was getting banned for no discernible reason - revealing the true IP addresses has stopped that.
I note also in that issue that PR’s have been released to address the issue with trusted networks and x_forwarded_for.
@bachya did you get anywhere with this?
It’s kind of useless having a mobile client that gets banned when you need it most.
I haven’t, unfortunately – other priorities took over. One challenge with this is that the banning mechanism is fairly tightly coupled with the http module; at the same time, that module is where the websocket API is defined (creating something of a circular reference). Long story short: I’m not convinced this is a simple implementation…
If my other, higher priority items cool down, I will definitely try to take another look at this.
4 Likes
Does anyone know if this was ever created? It’d be nice to be able to remove banned IPs without a restart. The z-wave network is a bit slow coming back up.
I ended up turning off IP bans in HA and now use fail2ban
1 Like
For some reason my kitchen Fully Kiosk Fire tablet seems to get banned after a while - haven’t a clue why.
The only thing I’m doing on that tablet perhaps more than on any other tablet is viewing external camera URLs. Often a precursor to the ban is the camera feeds start showing as unavailable images and the next time I go to view them it’s a 403 forbidden for the whole HA site.
Would dearly like to whitelist that IP so it never gets banned but don’t think this is possible?
2 Likes
same here after update to 0.107 using fully kiosk and tileboard.
All worked fine until 0.107
I’ve seen this happen when watching a camera feed that cuts out - I’ll see a notification for a login attempt with invalid credentials from my IP address. Not sure what’s causing it, but it’s definitely affecting more than just one user.
4 Likes
Damn, you are right! For a week now (v107.x), I’ve been getting IP banned over and over on connections to our remote lake house and could not for the life of me figure out who or what was creating the invalid login. Just now erased IP_Bans, restarted HA, logged in and tried to connect to a page showing 3 camera snapshots. Waited, waited, and no pictures ever came up… but the IP BANNED notification!
EDIT: yeah, the Internet connection at the remote location is often dismal these days. Upload well under 1mbit. Still, how does that explain an invalid login?
Hi! Got the same on my local network after upgrade to 107. I use stream component, but was not even opening this page.
Took a lot of digging, but in this post there was a mention of getting IP_banned after accessing remote cameras as well.
It was an old topic regarding the changes to trusted_networks in HA .89 so it didn’t seem at all relevant. But on a hunch, I added 127.0.0.1 (localhost) along with my local internal network as a trusted network and now I haven’t had any authentication errors accessing cameras.
I have no idea why localhost would be needed, or if it was something else I did in the mad scramble trying to fix it, but I no longer have any problem. So if you don’t have this currently defined in your auth_providers configuration, give it a shot and please confirm results.
1 Like
Unfortunately, this didn’t work for me, still getting authentication errors from iOS and web interface as well. I will try a bit later to add internal hassio addons subnet as trusted network, just for a test.
Just for information, I tried adding:
- my_home_subnet
- 127.0.0.1
- 172.30.33.0/25
to trusted networks. 172.30.33.0/25 is hassio add-ons subnet. And I am still getting authorization errors.
I will just wait untill 0.108 is out and, if ip_ban is not fixed there, will try to remove all camera streams from frontend for a test.
So it was something else in my case, not camera streams - I have now no camera streams at frontend and still invalid authentication attempts.
I am interested in last_authenticated sensor, how would you set it up? Thanks!
Use this
Then in configuration.yaml you will need this:
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
- ::1
ip_ban_enabled: true
login_attempts_threshold: 5
# Logger
logger:
default: warn #warn
logs:
custom_components.sensor.authenticated: debug
You will then have a sensor.last_successful_authentication you can display in lovelace like this:
1 Like
Thank you, This is really helpful!