Nextcloud bruteforce protection

Support
1

Lately our users start complaining about the 30 seconds delay for nextcloud login from our internal network. This also makes creating calendar entries in Thunderbird very slow and sluggish.

How can this be troubleshooted to find the source of the problem?

2

Hi, try editing in /usr/share/nextcloud/config/config.php
add this string:
‘auth.bruteforce.protection.enabled’ => false,

1 Like
3

@france has it right. I also use Fail2Ban along with 2fa and block all inbound 443 connections except for a defined white list.

1 Like
4

Thanks for your suggestions. For testing purpose I did deactivate bruteforce protection as you mentioned, which speeds up calendar entries creation as expected. I would like to know, how I can find out which ip is causing this. Where can I find this information?

Also it seems that all users are affected because of proxy activated, so one user triggering this by misconfiguration of one client resulting in slow connections to nextcloud for all internal users.

5

Reading in the nextcloud docs:
…If you run into a situation where login is often very slow for all users the first step is to inspect the bruteforce_attempts table. There you can see which IP addresses are actually throttled.

How can this be done within nethserver nextcloud?

6

@Elleni

Hi

This makes it easy to check the tables…

https://wiki.nethserver.org/doku.php?id=phpmyadmin

:slight_smile:

My 2 cents
Andy

2 Likes
7

Sure, but I would prefer not to install packages outside the normal repo for now, esp. as I proposed to my boss to buy subscriptions for our nethservers thus would like to not enable additional repo.

There must be an easy way to extract the needed info from console?

Did it by mysql -u nextcloud -p with password stored in /var/lib/nethserver/secrets/nextcloud, then use nextcloud db, show tables and finally select * from oc_bruteforce_attempts;

Now I only need to delete (delete from oc_bruteforce_attempts where ip = ‘1.2.3.4’; ) all those entries, and observe new entries and find the source / misconfiguration of those…

1 Like
8

As far as I know, brute force is set by default for all users, the wait is not derived from bad logins, but before logging in you must wait at least 10 seconds. This is what I know.

1 Like