How to disable or relax the bruteforce protection?

ℹ️ Support 📦 Appliances (Docker, Snappy, VM, NCP, AIO)
1

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.

2

Any ideas? We still face this issue…

1 Like
3

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
4

Thanks, I will try that!

5

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…

6

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).