Add ip_ban_whitelist for HTTP Integration

I also have this issue. Started about 2 weeks ago on version 2022.2.6. Cant remember doing anything to my setup the last month or so. It only happens to one device which is a wall mounted android tablet.
I don’t have a camera card and I am not using Cloudflare.

Update:
I believe my problems was caused by a custom component (Weather Card) that made Chrome constantly crashing (up to 30 times per minute!) and restarting on my tablet, and sometimes when it restarted it was not correctly authorized.

ditto all that shows in the logs is this, 3 of these and then my phone locked out, ( would say it happens now 4 times a day, reinstalled the app and still the same.

2022-06-07 17:28:14 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from RedmiNote9Pro-MarksP.mydomain.co.uk (::ffff:c0a8:240). (okhttp/4.9.1)

2022-06-07 17:28:14 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from RedmiNote9Pro-MarksP.mydomain.co.uk (::ffff:c0a8:240). (okhttp/4.9.1)

2022-06-07 17:28:14 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from RedmiNote9Pro-MarksP.mydomain.co.uk (::ffff:c0a8:240). (okhttp/4.9.1)

2022-06-07 17:28:14 WARNING (MainThread) [homeassistant.components.http.ban] Banned IP ::ffff:c0a8:240 for too many login attempts

For me the trouble is that the banned IP is 127.0.0.1 due to too many login attempts what makes Nabu Casa stop to work. It have happened twice in the last 2 months.

Luckily local IP address keeps working and it is easy to solve, but it may be a problem if it caughts me out of home since Nabu Casa is my remote login method.

1 Like

Agreed - it’s bizarre there’s no whitelist facility as things stand

wait, so adding that line doesn’t work? what about the trusted_proxies option?

The repository has been archived.

Someone willing and capable of cloning it and bringing this great integration back?

Logger: custom_components.hacs
Source: custom_components/hacs/base.py:885
Integration: HACS (documentation, issues)
First occurred: 22:37:57 (1 occurrences)
Last logged: 22:37:57

You have 'custom-components/authenticated' installed with HACS this repository has been removed from HACS, please consider removing it. Removal reason (No longer maintained)

I talked to „my it guy“ and he gave me a good and pretty simple workaround I want to share: just set the login attempts to e. g. 50 or even 100.
you won‘t lose significant safety concerning bruit force or dictionary attacks where we are talking about up to millions of attempts needed but won‘t lock out yourself anymore; as long as you use a strong and unique password of course.

3 Likes

I’ve got a situation where a particular computer must be attempting to authenticate using a ‘remembered’ method that Home Assistant once accepted but now doesn’t want to.
Anyway as soon as this computer tries to connect to the web GUI it’s banned.
Any ideas?!

Sadly this seems to be the only route but it greatly reduces your security. I run an offensive security team and anything over 3 attempts we recommend to bring down. There is a time period before this counter resets, so setting it to 50, an attacker can fail say 49 times in an hour rather than 2 times in an hour. Your IT guy should really look at the security. If your instance is Internet accessible then you’re opening up a larger can of worms.

1 Like

I get your point, in some sense it’s about up to 25 times less safe?
On the other hand, Mike Pound once stated in the famous Computerphile Password cracking video that any 8 character password could (7 years ago) maybe be cracked in a few hours up to a day at 14 billion hashes per second assuming an MD5 encryption (unlikely).
Now I hope I do the maths right: let’s say we could break any 8 character password in one second (!) of computer time with 14b guesses/s… Then if you get 49 guesses per hour, you have 1176 guesses per day resulting in more than 32000 years of guesses until the password is cracked. And I did not take into account 2 Factor Authentification or the fact that my password is of course longer and hopefully complex enough.
So I guess we are still kind of safe? At least this is my understanding at the moment, but I‘m absolutely no expert. Did I get something fundamentally wrong?

I’ve written a little integration addon that adds this functionality: GitHub - palfrey/ban_allowlist: Home Assistant plugin to add IP ban whitelisting. Note it does things in a bit of a hacky way (monkey patching the HTTP ban list code), but it does seem to work for me so far, and I’ve got fairly decent integration test coverage for it. Patches welcomed if there’s any missing features.

5 Likes

Does it supports ip range? Can you write an example with multiple ip in the configuration.yaml so we can se how to correctly write the list?

1 Like

Yep, if we can have an IP range that’s should be perfect.

Multiple ip example is already in the README. See

ban_allowlist:
  ip_addresses: ["my.ip.address", "another.ip.address"]

IP ranges: it doesn’t, because I don’t need it. Patches to fix this are welcomed though.

Any future feature requests should be done as issues on the repo, as I’m not here that often, but I pay attention to Github a lot.

2 Likes

Is there any solution to this after all these years? I start to be banned on my own home network… This is very annoying

2 Likes

With the exception that people usually use easy to guess passwords. I don’t brute force a form or auth page. You are talking about if you get the hash and brute force that offline. When targeting a page I will try to either see if the user has already known beached credentials that I can mutate or start using top few thousand lists in hopes that is weak. I’ve gotten domain admin in international organizations by guessing P@ssw0rd! … People be dumb some times.

1 Like

Thanks for sharing a solution! Working nicely for me so far.

I know you said you don’t need it, but I’m not a Python coder to submit a patch either. I think a simple string compare to the first three quads if there is an asterisk to match to in that list would work just fine and make a lot of people very happy sir…

As per your request… REQ: Please add CIDR notation or a wildcard for the last quadrant · Issue #3 · palfrey/ban_allowlist · GitHub :pray:

Great to see there finally IS some kind of „solution“ for this - even it is a „very hacky“ way and tbh feels kinda dangerous to use a custom integration for such a (even security related) core component.

In short: if a custom integration developer can do this, why isn’t it possible to natively add this to the core? I think that is the actual way to go - now that it is proven it is possible.

Did you think about porting this to the core @palfrey?

Hi, I noticed something interesting. I never had issues with banning my own IP address because of the companion app and started recently. I decided to troubleshoot what did I change recently that caused this to happen. I did some network changes and I had to put HA on DHCP so I don’t loose access to it after the change. The IP was anyway reserved so would not change. When I changed back to Static IP, no more banning!!! It might be that when the lease expires, takes a few minutes to renew and in that time the problem occurs, just trying to guess…
I found in logs below:
[supervisor.resolution.checks.base] Run check for IssueType.DNS_SERVER_FAILED/ContextType.DNS_SERVER
Some people reported this happening on DHCP or Static IP. I hope my post will help other people with odd banning issue.