we are currently experimenting with Nextcloud for exchanging files with external users and customers.
Yesterday someone used the Nextcloud mobile device client with wrong credentials. This caused the brute force detection to kick in and making log ins from our internal subnet very slow.
Some questions in regard to this since the manual didn’t provide much informations on this or may be I missed it.
Are all logins from a specific subnet / IP slowed down if brute force detection has kicked in ?
Is the database table cleaned up after some time by a cron job ? I mean like everyday midnight ?
If #1 is true this could cause serious trouble for us if some internal user enters a wrong PW multiple times and this causes slow logins for any other inhouse user when accessing our Nextcloud server.
Hopefully someone can shed a bit of light in my darkness
Thanks for your reply ! So one stupid / unaware user can cause big troubles here
What about an included cleanup job ? Is something like this available or do I need write a small sql script cleaning up the table ?
Thanks for pointing out that I can disable this but I would rather leave this in place with some automatism behind cleaning up all entries from our internal subnet at a choosen interval.
Sorry, I was shure, they are cleaned from the database. But now I hat a look into my database and saw, that I have Data in oc_bruteforce_attempts table since August 2016.
I have a further look and will come back to that thread…
So one stupid / unaware user can cause big troubles here
It would be very nice if you can give me feedback on the cleanup.
BTW: The disable flag for bruteforce detection in the config.php seems to be ignored if there are any entries in the oc_bruteforce_atempts table. Only if the table is empty the flag seems to be valued by Nextcloud.
This is similar to what we did yesterday by truncating the table
But in the end there seems to be no automatism but any user from a certain subnet gets slowed down for ever once he is on the blacklist. I am not shure if this is a great idea. Especially if you run into this issue for the first time. We had first other issues in mind when the login took so long. Like slow database or problems with the webserver.
I guess both a flag about a kicked in brute force detection in the webfront end plus some option to clean the table automatically would be a nice enhancement.