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).
Brute force protection is generally a good idea, and what is allowing your users to use short (below 12-16 characters) passwords. Computers now aday are so fast and can try many many passwords per second. If you don’t have it all of your users will need to change their passwords north of 20 characters.
Note that it is probably enough that a single app on some device is still using the old password to trigger a failed password. All of your users needs to be trained to change on all of their devices at once. Also I would whitelist my own black addessed/non routable network to allow some mistakes from my family while making the installation way more secure from the rest of the world. In some cases(instances/conditions traffic from the outside world can be forwarded to your private network looking like it came from your router, so failed password attempts coming from your router can be a serious thing.
I don’t know if it is an option for you but I run tailscale on most of my devices. That way I know only my stuff can send traffic to my services - they simply aren’t reachable outside tailscale.
hi, 1st of all THANKS to all who answered, and sorry for my late response!
Thanks esp. to @jtr and his remark “BFP ONLY triggered by FAILED logins”:
Digging that’s why more into logs etc., I found out that in fact an stone age old Akonadi cardDAv/calDAV link on my Linux PC was the “culprit”. NO IDEA exactly why, maybe a somehow outdated app token, or myself, as after KDE/Plasma login it takes a while until my kdewallet asks for unlocking, whereas these two Akonadi links are much sooner asking for their passwords… Thought I always clicked “cancel”, but who knows …
Re- created them, and all of a sudden no BFP lockouts anymore…
SO I BEG YOUR PARDON for a) wasting your time and b) distrusting our BFP concepts
And sharing is a protected endpoint.
