Installing the Brute Force App only reveals the Brute Force security system shipped in stable releases is throttling the ips of admins.
I’m not quite sure what problem you’re trying to solve.
First of all, the bruteforce protection doesn’t permanently blacklist any IPs, it just delays login attempts for IPs from which multiple failed login attempts have originated, which shouldn’t happen for IP addresses or devices that are legitimately trying to access your Nextcloud in the first place. If it does happen, it’s usually because some client application is trying to access the server with wrong/outdated credentials.
If you really want to permanently exclude certain clients or network segments from brute force protection, you can do so via brute force settings app, which is enabled by default in recent Nextcloud versions, but this shouldn’t usually be necessary and it would be better to find the root cause of why legitimate IPs are being throttled instead of whitelisting those IPs.
And if all else fails, you can always manually reset the login attempts for a specific IP using the occ command, which should allow you to log in again immediately: Using the occ command — Nextcloud latest Administration Manual latest documentation
1 Like
There is no logic in the code to prevent logged in Administrators at that particular IP from being throttled is there?
For example an Admin has two accounts logged in from a single ip on different browsers and desktop clients, one of those logins is an admin account. Is the IP of a logged in Admin always whitelisted?
As far as I know, no, because it works on a per-IP basis, not a per-user basis. What I don’t know for sure is whether or not it will also affect users and applications that are already logged in when it is triggered.
So my question to you would be: Does it do this, or have you actually experienced this?
And if so, why is it a problem, or what is beyond your control that triggeres it in the first place?
I mean, if another browser or application on your computer triggers the brute-force protection, make sure that doesn’t happen by using the correct credentials for all of your accounts in all of your apps. Use login flow wherever it’s supported, or app passwords for client applications, in which case those apps won’t cause problems when you change the password of the corresponding accounts. And for manual logins in browsers, there are password managers to prevent you from typing the wrong password multiple times 
The only situation where I can see this becoming a real problem is if many users and devices are accessing the Nextcloud from the same IP address, either because the Nextcloud is hosted externally, or if it is hosted locally because you are using NAT loopback instead of split-brain DNS.
In the first case, it might actually make sense to whitelist the public IP of the Internet connection from which most of your users access the externally hosted Nextcloud, and in the second case, you should use a local DNS server for split DNS to prevent all your clients from appearing in the Nextcloud with the same IP address.
Of course, a single device/computer will always have the same IP address for all browsers and applications that are installed on it, so there it’s up to the user of that device (you!) to keep track of all installed applications and accounts, and to always use the correct credentials.
2 Likes
I’m sorry you are looking for the false solution. each and every security mechanism should apply even harder for admin accounts. the worst scenario is If the attacker somehow manages to brute-force your admin account - excluding admins from brute-force protection is nonsense. Admins usually have the power to unlock the false positives using occ but in case this is a legit hit you better rely it kick-in fast.
1 Like
I am a little stunned, because the admin account logged in was notified in the administration settings overview that it’s own ip was throttled.
This is not a security feature but a bug. Bugs are Security vulnerabilities and a false sense of security.
Note: I do not want to characterize negatively the developers whom have contributed the the project personally. I am grateful for the project and the contributors without hesitation.
What if there is a local lan and there are good and bad users on it, the lan broadcasts as a single ip to the outside internet.
The logged in administrator in this scenereo is throttled, as is the bad user who is brute forcing into the system. Shouldn’t the administrator account not be throttled and the bad user be throttled?
Why is the Brute Force system not able to exclude logged in administrators from being throttled?
Generalizing that strict is better than tollerant is in coherent logic.
Even on a local LAN, each device has a unique IP address. And with a proper split-brain DNS setup, a locally hosted Nextcloud server can see these IPs and then only slows down login attempts coming from the specific devices that are causing the failed login attempts.
If your server is externaly hosted the brute-force protection can obvioulsy only see the the public IP address of your internet connection, and therfore not distinguish from which local IP address the log-in attempts are coming from. In this case, it cannot help you to slow down login attempts of bad actors inside your local LAN, and it’s probably best to whitelist the public IP of your internet connection.
Again, this is because it does not prevent specific users from logging in, but rather slows down login attempts coming from IP addresses that have already caused multiple unsuccessful logins in a given time period.
In short, it’s IP-based, not user-based.
1 Like
The screenshot you posted says:
[…] is not actively throttled at the moment.