I’m using Nextcloud for years now, and love it! Own OpenSuse VPS, most important server-side apps for us (my family) are Calendar and Contacts. Foto/Video upload via Nextcloud App on Android. ALL our devices (Smartphones, iOS/Android, “Fritzbox” router [synching contacts to catIQ DECT phones], Win PCs, Linux PCs) uses our centralized NC adressbooks and calendars. For YEARS now, since at least 2015. Started with Owncloud, that time. Easym and user friendly!
BUT: The current brute-force “handling” has “evolved” IMHO to a real pain in the neck!
There are many threads here with exactly my topic:
small “home install”, several devices accessing via (W)LAN from home
all of them that’s why with same external IP, v4 and maybe v6, provided to router from ISP
very often, and more worse increasing, lock-outs by NC.
And what I’ve seen/read/found absolutely no other “solution” than disabling brute-force detection completely!
IMHO it’s more than questionable why brute-force detection jumps in here, as for these clients-behind-SOHO-router scenarios usually there are NO FAILED logins, all devices and apps are using correct credentials. So maybe we can discuss about a potential DoS detection. But as this still means “potential DoS with CORRECT credentials”, all of this IMHO really should be configurable by NC, not only on/off!
For me, personally, disabling DoS detection by disabling NC’s “brute-force” detection is NOT an issue, as it’s my “own” VPS, and fail2ban is doing EXACTLY these 2 jobs, much longer, much more stable, and nicely configurable.
But there are many users out there, using e.g. a hosted NC, who I guess would benefit from a better brute-force handling.
very often, and more worse increasing, lock-outs by NC.
Can you be more specific? What are you actually seeing? Specific error messages and/or log entries? i.e. see BFP: Troubleshooting for examples of what to look for/check.
all of them that’s why with same external IP, v4 and maybe v6, provided to router from ISP
If you have a Nextcloud instance that is not misconfigured, brute force should not be triggered. That is why in your situation I would try to find out what is causing it.
The link you posted only states vaguely:
Nuisance triggers are minimized through reasonable built-in defaults appropriate to each type of action.
As a temporary solutions until you find your issue, I would suggest that you add 192.168.178.0/24 to your whitelist. That way all devices from your local network won’t get blocked.
I probably should have just said “authentication” rather than use the word “login” (I assume that was your point since we seem to mostly agree on what OP should consider doing…).
Invalid authentication attempts (i.e. anything involving passwords or tokens) can happen via any protected endpoint. Nextcloud has numerous endpoints which are covered by BFP.
I’m familiar with the Issue. And sharing is a protected endpoint.
Without more information from OP I don’t know why they’re experiencing what they are though.
As you hinted (and why I requested more info from OP), configuration matters such as an improperly integrated reverse proxy can lead to connections all appearing to originate from the same IP address (from Nextcloud’s perspective). In that case, whitelisting is not the answer.
Though other scenarios, such as having many users connect from a single location (which seems to be at least part of OP’s situation), can lead to problems.
Fortunately, that’s why BFP has support for whitelisting specific IP addresses. It’s unclear if OP is aware of that or has tried it:
And what I’ve seen/read/found absolutely no other “solution” than disabling brute-force detection completely!
[…]
So maybe we can discuss about a potential DoS detection. But as this still means “potential DoS with CORRECT credentials”, all of this IMHO really should be configurable by NC, not only on/off!
OP seems to have a remote Nextcloud Server and the users mostly connect from a common location (not located where the server is and all sharing the same public IP address presumably). Assuming everything else is configured appropriately (i.e the reverse proxy integration), that scenario is described in the docs as a fair candidate for whitelisting of the relevant public IP address. BFP, however, would still be enabled.
(Note anyone that comes across this: To access BFP settings - such as whitelisting - does require enabling the bruteforcesettings app if in <v30. In >=v30 the app is enabled by default).
And sharing is a protected endpoint.