Nextcloud version (eg, 20.0.5): 27.1.0 beta 3
Operating system and version (eg, Ubuntu 20.04): Debian 11 in VirtualBox 7.0.10
Apache or nginx version (eg, Apache 2.4.25): 2.4.56
PHP version (eg, 7.4): 8.2.8
The issue you are facing:
After upgrading to 27.1.0 beta 3, the security scan gives the following error:
“Your remote address was identified as 192.168.1.1 and is bruteforce throttled at the moment slowing down the performance of various requests. If the 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.”
Is this the first time you’ve seen this error? (Y/N): Y
Steps to replicate it:
Upgrade to 27.1.0 beta 3
Select “Administration settings” under my profile avatar
I am not aware of any proxy in use, and this issue just began after the upgrade. Prior to that, my security scan all came up successfully (no errors).
Sorry for the slow response. I was expecting a notification in my email, but I must have missed it.
Yes, 1.1 is my router. I have external DNS entries pointing to my home WAN, and then ports 80 and 443 are port-forwarded to my internal Debian instance which runs Nextcloud. If it matters, that Debian is a VM running in VirtualBox. But it worked fine until recently.
This has worked great for the past two years, but something has changed, and I’m not sure what. I recently upgraded to 27.1.0 RC1. Prior to that, I was on the latest 27 beta. I was wondering if perhaps the bruteforce app just got more stringent or something. Maybe the problem has existed longer than I realized. But prior to this, I would routinely check my status, and it would say “all checks passed.”
Additional info:
It’s inconsistent – today, when I checked for RC2, I got the bruteforce error. However, after upgrading to RC2, I am getting “all checks passed.”
It seems like it’s done this before – hit and miss on the error message.
Similar problem.
Appeared after updating to 27.1.0 RC2
The server is located on the local network.
Message text:
Your remote address was identified as “10.10.10.100” 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 .
I’m now up to RC4, which just became available to me today. I’m trying to keep on the very latest. As of right now, I’m getting “All checks passed.” Let’s keep our fingers crossed…
But even on RC3, it would randomly fail, then pass other times. Without making any other changes, I could run the test twice in a row…and one would pass while the other failed.
I guess I’m also a little confused. These are local private addresses (192.168.1.1). Why would that be a threat? I’m on my home local network, accessing my Nextcloud server. I didn’t think those addresses were routable over the internet, so why is this considered a potential intrusion?
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 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?
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
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?
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!
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";
.