How to delete a blocked IP from brute force db table when table seems to be empty?

Hello,

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?

If fail2ban had been installed, please check, whether the IP had been blocked in fail2ban instead of in bruteforce.

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…

1 Like

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.

3 Likes

That explains a lot! :slight_smile: Thanks! :+1:

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

1 Like

Thank you! If I am not mistaken, there is no other way than browsing the log file to find a blocked ip, is there?

sudo -u www-data php /var/www/nextcloud/occ security:bruteforce:list

does not work.

see:

Manuals are so helpful, but everybody ignores them :sleepy_face:

I saw these commands, and hence my question, because there is no option mentioned that will list all blocked ip.

1 Like

Try your public IP address as well as the local IP address of your workstation.

You also can issue a feature requenst on Github

It’s currently technically not possible to list the ips with the redis backend.

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.

Finally, in addition to the occ command reference (which only has minimal context), there is a full chapter dedicated to BFP: Brute force protection — Nextcloud latest Administration Manual latest documentation

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?

Thanks for explaining!

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.

Yes, I certainly will!

Is there no log file that contains this information?

Please find the /var/log/redis/redis-server.log maybe you will find there information about blocking.

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.