How to disable or relax the bruteforce protection?

We have a big problem with blocked logins because we are running NextCloud in a Docker environment and whenever a user repeatedly tries to log in with wrong credentials, the internal IP of the service is blacklisted and no-one can login anymore since the IP is the same for each user. Maybe I misinterpret this, but at least this is what we observe.

Here, 10.0.9.107 is the IP of the Docker service running NextCloud and not the IP of the user.

| 24 | login  | 1680161275 | 10.0.9.107 | 10.0.9.107/32 | {"user":"foo"} |
| 25 | login  | 1680162056 | 10.0.9.107 | 10.0.9.107/32 | {"user":"foo"} |
| 26 | login  | 1680162082 | 10.0.9.107 | 10.0.9.107/32 | {"user":"foo"} |
| 27 | login  | 1680162328 | 10.0.9.107 | 10.0.9.107/32 | {"user":"bar"}    |
| 28 | login  | 1680162356 | 10.0.9.107 | 10.0.9.107/32 | {"user":"bar"}    |
| 29 | login  | 1680162958 | 10.0.9.107 | 10.0.9.107/32 | {"user":"foo"} |
| 30 | login  | 1680162984 | 10.0.9.107 | 10.0.9.107/32 | {"user":"foo"} |
| 31 | login  | 1680163175 | 10.0.9.107 | 10.0.9.107/32 | {"user":"foo"} |

I repeatedly need to truncate oc_bruteforce_attempts; to enable the login again. Is there a way to relax this?

The main cause of this is that we recently switched to a new LDAP service and some people are still running clients on their laptops/phones/tables with the old credentials.

Any ideas? We still face this issue…

1 Like

I would really advise against trying to disable bruteforce protection, instead make sure that the correct IP of the client is known inside the container. You need to set trusted_proxies and maybe adjust the header with forwarded_for_headers, see Brute force protection — Nextcloud latest Administration Manual latest documentation

2 Likes

Thanks, I will try that!

I read through the docs and also found NC20 isn't respecting 'X-Forwarded-For' header from reverse proxy - #12 by Master which seems to be related but for whatever reason, still the “internal” IP is logged and the forward does not seem to work.

The trusted_domains settings looks like this:

  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'the.domain.of.the.server',
    2 => '10.0.9.107',
    3 => '10.0.9.*',  // added a wildcard in case the IP changes, might need class B
  ),

and I added this to look for the header entry from HAProxy

 'forwarded_for_headers' => 
  array (
    0 => 'HTTP_X_FORWARDED_FOR',
  ),

So no luck with this yet. I’ll dig deeper, but if anyone has a working solution for this (HAProxy + Docker Swarm), I am happy to listen…

argh, I confused trusted_domains with trusted_proxies

  'trusted_proxies' =>
  array (
    0 => '10.0.9.107',
  ),

this did the trick… (may need some wildcard due to the swarm IPs though).

I’d still like to be able to disable brute force detection. We are running our nextcloud instance within a private network, and no access from outside is possible. Brute force detection makes little to no sense here and I think there just SHOULD be an option to disable it anyway.

For now, I’ll try to relax it using the directions from this thread.