On the local machine, all checks pass. It’s very strange why it swears at the computer from the local network.
I log in from a remote machine, everything is OK too.
Apparently this problem only occurs on the local network.
A few thoughts off the top of my head. Apologies I don’t have the time to organize these a bit more for you today:
The check runs from your browser so it’ll be different on each device you run it from (or, at the very least, each connection you try it from).
The check for whether the admin is throttled is new, but it doesn’t mean you weren’t being throttled before - just that you weren’t aware of it. The idea was that now the setup checks give an indication when this situation is detected.
The inconsistency may also just be due to your IP address expiring out from the brute force IP table (it’s ~25 minutes IIRC but I don’t recall all the logic behind it off the top of my head).
Given your network topology, you may want to install the BruteForceSettings app and experiment with whitelisting your home router IP address as a start:
The other possibility is that there is something weird about your network topology where you’re sometimes going through your router… and other times not (Proxy ARP comes to mind).
One way of avoiding having your connections bounce through your router’s when you’re local would be to use split DNS. That way when you’re on your local network you’d not go out to your WAN IP address and back. It’s possible that’s creating some weirdness (often it doesn’t even work on consumer routers or, in my experience, even when it does it’s flaky or impacts performance.
Thank you. Adding exceptions helped.
Thank you for that info. I’ll keep playing with it.
For now, I just made one exception in the “Bruteforce IP White-list” section under the “Security” tab. I added:
192.168.1.1/1
So far, that seems to have stopped it.
I was trying to read up on this bruteforce feature. I thought it was only supposed to trigger if an attempt was made to login, but with a WRONG password. Is that something different? Am I confusing two different sections of the security?
Did you add exceptions in the “Bruteforce IP White-list” section, under the “Security” tab?
Or elsewhere?
Added to Bruteforce IP Whitelist
For whome it may interest!
2 days ago i’ve updated from from 27.0.2 to 27.1.0.
Since then Nextcloud ‘feels’ quite a bit slower, but I’ve seen no error message.
Today I’ve updated from 27.1.1 and I got that message immediately:
“Your remote address was identified as 10.0.2.100 and is bruteforce…"
After struggling with that mentioned documention I fortunately came accross this thread.
I’ve just activated that app ‘Brute-Force-Settings’ and the error was gone; no whitelisting, no 'trusted-proxies in the config/config.php.
Restarting Nextcloud, restarting the server and no error.
Nextcloud feels definitely quite bit faster.
Setup:
Nextcloud is setup using a Podman Pod on Almalinux 9.2 with rootless containers (it’s not the AIO solution). There are dedicated containers for Nextcloud, PostgreSQL, Redis, Nginx, Cron, Elasticsearch, Borgbackup, …
Nginx is the reverse proxy within the pod.
My instance was rising this since having upgraded from " 27.1.0" to " 27.1.1"
Edit (23. Sep.):
I encountered this yesterday but not today. Don’t know what’s goin on. During night time a backup has been done including a cycle of “maintenance:mode --on” and “–off” again along with other services/tasks to be restarted.
Having the same issue here since I upgraded to 27.1.1 ==>
Following @mf-in-mun advice, I just enabled the Bruteforce Setting app (it was already installed by default) and the error was gone
Experiencing the same after upgrading to 27.1.1
Just installing the bruteforce settings app didn’t cut. I can blacklist my router’s IP but then I guess it would just effectively completely disable brute force protection, wouldn’t it?
Isn’t there something wrong with nginx configuration? Shouldn’t nextcloud see my real IP instead of my router’s?
1 Like
Fresh: Nextcloud Hub 6 (27.1.1)
In my case it seems, because I tried to edit the smtp settings, while my browser session was “expired” and while editing smtp, several times a window appeared asking for my nextcloud password. But it seemed it could not take the password! …and was demanding after some seconds again the password!
…and now under: my.nextcloud.com/settings/admin/overview
Nextcloud Your remote address was identified as “xxx.xxx.xx.xx” and is bruteforce throttled at the moment slowing down the performance of various requests. If the remote address is not your address this can be an indication that a proxy is not configured correctly. Further information can be found in the documentation
.
Solution for deleting a blocked IP address:
In the terminal open your database, e.g. MariaDB
use your database
select the table oc_bruteforce_attempts
delete your ip addresse:
mariadb
USE nextcloud_db;
SELECT * FROM oc_bruteforce_attempts;
DELETE FROM oc_bruteforce_attempts WHERE IP="xxx.xxx.xx.xx";
1 Like
Better (simplier) solution for security (or the same effect):
occ security:bruteforce:reset <ip_address>
2 Likes
Experiencing the same after upgrading to 27.1.2
I added the ip address 192.168.x.x/32 in the “Bruteforce IP White-list” section under the “Security” tab. So far, the problem is gone.
Have the same problem with my setup (where NC is running behind a reverse proxy). I checked that my proxy is setting the X_Forwarded_For header correctly, which was the case.
Also, the Nextcloud Throttler is actually trying to get the original IP from the visitor, so I’m not sure why the Proxy IP is popping up in the Throttle warning at all.
This worked for me on my server with a public facing static IP on NC 27.1.3
Thank you.
And your proxy is defined as a trusted proxy ?
Thanks! I just did that and it went from slow 20 seconds to never log ins to fast again.
But… I don’t know why this was needed.
I have a home lab with a Dell blade server. I have running 3 versions of next-cloud from 23 25 and 28. The fastest is version 23.xx
They get progressively slower and version 28 is the worst.
I log in from my workstation 192.x.x.x and the VM next-cloud on same subnet. This is how I build and test them. Why would this issue be wanted on a default installation? Was never an issue till the new and slow versions.
Why do I have to whitelist when I did not before?
Its fixed I just do not understand the why of it. Anyone?
If you set your log level to INFO (1) then whenever BFP is triggered, it appear appear in you logs.
Your logs will tell you why/what connections are triggering the BFP. The only thing that can trigger BFP is invalid login attempts from a particular source IP address.
You may want to read the recently updated chapter covering BFP in the Admin Manual. It may provide some hints that will help you sort out why it’s being triggered in your environment.
Thanks for the information.
I did set logs to 3 and removed the white list. After a 2 bad log in attempts (on purpose) the warning came back.
The log says this.
no app in context IP address throttled because it reached the attempts limit in the last 30 minutes [action: login, delay: 200, ip: 192.168.0.114]
I’m thinking the brute force detector has changed since version 23 to 27. I never triggered before the new version with the same settings and sever same router etc.
How many log ins does it take to trigger it? I did 2 or 3 bad log on attempts and it went off.
Also how does the throttle last or the setting for it?
I made a 2nd test account log in using a 2nd gamil account. I’ve done that in all my testing so that is not new. The new is the early trigger and sluggish log on speed. The warning logs do go away long as I don’t try log out then log back in.
So each log on triggers it. I tried with the same php settings on version 25.xx and cant get a log throttle warning. So something has changed between 25.xx and nextcloud 28.xxx
This might not apply for web long ons just in a network setup.
Nice pick up Lionel.
Fixed my error efficiently!