I have a bit of understanding trouble here, when it comes to manipulating db tables. I tested the brute force settings and the good news is: it’s working. Bad news: unblocking the banned ip turned out to be a bit tricky.
First think that strikes me: there’s no GUI element inside NC to do this. This is sad.
Next strangeness:
MariaDB [nextcloud]> SELECT * FROM oc_bruteforce_attempts;
Empty set (0,001 sec)
So, apparently, the table is told to be empty, meaning: no ip is blocked. But that is not true as a simple test revealed.
Luckily, I could look up the ip in question through the log file, and the next command worked:
MariaDB [nextcloud]> DELETE FROM oc_bruteforce_attempts WHERE IP="1.2.3.4";
Query OK, 0 rows affected (0,001 sec)
After that, the ip was unblocked, even though mariadb tells me that “0 rows where affected”, which I would interpret as “just keep moving, nothing to see here, nothing to be done.” Meaning there was nothing to delete. But that was not true, very obviously.
So, what did I do wrong there? Why does the db command not show the entries of the selected table? How should I change the command to work in the first place? Would be nice to know for future issues.
And I think there should be a more convenient way to manage this list. Is there a security issue for not integrating this feature into NC or is just because no one has cared to write an app for this yet?
Fail2ban has not been installed yet. The ip was blocked, it was not able to connect, and the only candidate for doing so is NC’s bruteforce setting. I am not complaining about that, because that is exactly what I want to happen. I simply do not understand why mariadb tells me the list of blocked ip was empty, but at the same time a specified ip could be removed from an “empty” list.
This is very strange to my, and I can’t call Scully at the moment…
Hey, the database command did infact nothing, it might be a coincidence that it worked. Nowadays (by default) redis is used to store the bruteforce information. To correctly reset or check for bruteforce protection, use the provided occ commands.
You can use the occ command if the IP address is blocked in Nextcloud:
Example: sudo -u www-data php /var/www/nextcloud/occ security:bruteforce:reset 82.66.187.XX
I won’t touch on the Redis aspect since that’s already been discussed.
I will add this since it may explain the “coincidence”: BFP isn’t really a blocker; it’s mostly a throttler:
An IP being subject to BFP doesn’t prevent authentication (mostly), it just makes it take increasingly longer.
A successful login from an involved IP clears the delay.
The “mostly” part is that really high rates of excessive invalid login attempts in under 30 minutes can trigger temporary HTTP 429 blocks; but it’s a sliding window, so as long as the attempts stop, the prior attempts will age out of the window (and, in turn, the blockage).
Also, different actions are penalized differently / delayed independently.
Lastly, a successful login (not necessarily through the same endpoint) as long as it’s a comparable action type can reset the system.
P.S. What are the specifics of the situation you find yourself in that necessitates showing all IP addresses? Are you routinely encountering false positives? Or are these real-world end-user connections that are somehow triggering it under otherwise normal conditions?
No, not yet. And I very much hope it will stay that way. My question about how to list all blocked ip was just a question if there is some command that would make unblocking a bit more convenient.
I see what you mean. On the other hand: if I interpret my search for redis and logfiles correctly, redis is said to be able to create several kind of log files. It’s sad that still no information about blocked ip is available.