Bruteforce protection triggered by using certain apps (FolderSync, DAVx5, Floccus etc.)

ℹ️ Support
1

I use multiple apps to sync data with Nextcloud:

  1. FolderSync in Android to sync a number folders between Nextcloud and the Android device. Some of the folders can contain up to 4000 files.

  2. DAVx5 used for CalDAV/CardDAV to sync addressbook and calendar.

  3. Floccus to sync bookmarks between a browser (Vivaldi) and the Nextcloud bookmarks app.

I created a separate app password for each app and in general it works OK.

However I often experience the problem that just running the sync in FolderSync will create dozens of records in the oc_bruteforce_attempts table. Also DAVx5 and Floccus sometimes trigger that.

Sometimes even the Nextcloud desktop client won’t work any longer.

I have then to manually remove the records from the table oc_bruteforce_attempts.

Nextcloud is hosted on a public server mit 32 GB RAM, 6 cores, 1.5 TB SSD for storage without a reverse proxy and hosted using PHP 8.1, Apache 2.4, MariaDB, Redis and APCu. Everything is already tuned for performance since the server is a system for about 40 users. fail2ban is not used. I’ve been using and maintaining Nextcloud servers since release 12.0.0 - I never experienced a problem like this in the last couple of years.

Can it be that Nextcloud 27.0.0 does not like many logins in a short time period even if they are totally legit with correct credentials?

Edit:

I changed the the memcache.locking to use Redis with a local socket instead of an IP socket (and configured Redis on that machine to provide a file socket as well of course):

  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/run/redis/redis-server.sock',
    'port' => 0,
    'dbindex' => 0,
  ),

This improved the situation a it, but there are still records created in oc_bruteforce_attempts when the sync is executed by any of the apps.

In addition to the reported problems FolderSync sometimes trigger OCA\DAV\Connector\Sabre\Exception\TooManyRequests.

Any ideas?

3

Update:

After some more investigation I found out that rate limiting may cause HTTP 429 responses along with log entries referring to OCA\DAV\Connector\Sabre\Exception\TooManyRequests. Another side effect seems to be, that apps will then retry the requests which will then catched by the brute force protection as well.

As a temporary workaround I turned off rate limiting with the following configuration setting in Nextcloud (config/config.php):

 'ratelimit.protection.enabled' => false,

However - no change at all. I tried a number of sync runs and after two or three runs the same situation: Nextcloud will start sending HTTP 429 - eventhough the total number of requests is not that high, maybe 10 requests within 20 to 30 seconds.

Then I turned of brute force protection as well, just to see what happens:

  'auth.bruteforce.protection.enabled' => false,

At that time I was the only active user on the server and in the web server log there were no activities at all besides my own tests.

Now it seemed to work. However for security reasons it should not be done this way.

The I disabled Floccus to avoid having too many clients trying to do syncs at the same time since. Now I can at least let brute force protection be enabled again. But without disabling the rate limit, the whole setup is not really usable.

I see the point of protecting the server with rate limiting and brute force protection. But in this case I believe something is not right here. Having a request every 2-3 seconds from a logged in user should not cause any issue. The server can easily handle hundrets of requests per second if neccessary.

I also wonder what changed - with Nextcloud 26 and before I never had such problems.

1 Like
4

Ok, the mystery is finally solved… :see_no_evil: :crazy_face:

A long time ago I had to use Edge for a certain job and also installed Floccus, so I could keep the bookmarks in sync with another browser. Recently decided to clean up my old app passwords and also deleted the old Floccus password since I did not expect this to be needed any longer and I do not use Edge any more as well.

However - Edge was still running as background process even if not opened! And this also meant that Floccus within Edge also tried to sync in the background with an old app password which did not exist any longer. And of course Nextcloud did its job and protected the account. I just connected this to other sync jobs and did not realize that these jobs did not to anything wrong at all but it was Edge with Floccus all the time.

I found this out when checking the access log of the webserver which contained the user agent string of Edge along with login errors for the bookmark app.

I removed Floccus from Edge since I don’t need it there any longer anway and now everything is back to normal also with rate limit and brute force protection enabled :slight_smile:.

Lesson learned: some problems are a bit more complicate to solve and if Nextcloud blocks accounts because of wrong passwords, then there is a reason for it which has to be found.

1 Like
5

I’m currently having the same problem with a client’s nextcloud installation. We synchronize calendars with iCal, iPhones and a web booking system.

Out of the blue I suddenly get the same OCA\DAV\Connector\Sabre\Exception\TooManyRequests errors. I know there are many requests but I can’t really dial them down. Also, I too would prefer a solution that doesn’t completely disable bruteforce protection.

Is there a way to make the function less agressive?

Addition: I found this:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/bruteforce_configuration.html