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

7

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.

8

Hello! I have a question about this, i run a Debian VM(inside Proxmox on a Raspi) with NextCloudPi with an access from the web via dynDNS. When i try to login from the web over my dynDNS-address i get the same error message, but when i try it locally it works fine

I tried the settings in config.php but it doesnt work for me, i installed no reverse proxy, or is there an automatic reverse proxy with the NextCloudPi Project? I think i tipped “No” when there was a question for a proxy during installation

i have a dynDNS because i have no static IP for my Router at home
Here my settings:
‘trusted_proxies’ =>
array (
11 => ‘127.0.0.1’,
12 => ‘::1’,
13 => ‘https://mydynDNS.org’,
14 => ‘77.xx.xx.xx’ (this was my IP from today),
0 => ‘“mydynDNS.org”’,
1 => ‘192.168.178.10’,
4 => ‘192.168.178.0/24’,
5 => ‘203.0.113.45’,
6 => ‘198.51.100.128’,
7 => ‘192.168.178.1’,
),
‘trusted_domains’ =>
array (
0 => ‘localhost’,
7 => ‘nextcloudpi’,
5 => ‘nextcloudpi.local’,
8 => ‘nextcloudpi.lan’,
3 => ‘mydynDNSl.org’,
11 => ‘77.12.xx.xx’,
1 => ‘192.168.178.XX’,
14 => ‘nextcloudpi’,
20 => ‘m,ydynDNS.org’,
21 => ‘127.0.0.1’,
22 => ‘192.168.178.10’,
),

‘forwarded_for_headers’ => [‘HTTP_X_FORWARDED’, ‘HTTP_FORWARDED_FOR’],

9

When i try to login from the web over my dynDNS-address i get the same error message, but when i try it locally it works fine

What error message specifically?

If you’re not using a reverse proxy, then the above values for trusted_proxies are unnecessary. In addition, even if you are using a reverse proxy, the only entry you should need is the IP address of your proxy. Lastly, hostnames and URLs (e.g. https://) are completely bogus values to have so those need to go.

For trusted_domains you really only need 1-3 values in most cases: your permanent hostname (e.g. blah.mydyndns.org) and then maybe localhost and/or 127.0.0.1 and/or your internal IP address). Since you’re using NCP, I supppose it’s a good idea to keep the nextcloudpi* ones too. There is no need to update this constantly when your public IP address changes unless you’re not using your hostname to access Nextcloud for some reason.

10

I translated it from german: Several invalid login attempts from your IP address have been detected. The next login will therefore be delayed by 30 seconds.

The question is, why does the bruteforce app detect these logins as risk. I can show the oc_bruteforce_attempts in mariadb if this can help too

I changed my trusted domains to:

‘trusted_domains’ =>
array (
0 => ‘localhost’,
7 => ‘nextcloudpi’,
5 => ‘nextcloudpi.local’,
8 => ‘nextcloudpi.lan’,
14 => ‘nextcloudpi’,
20 => ‘“mydynDNS”.org’,
21 => ‘127.0.0.1’,
),

I changed the trusted proxys to:

‘overwriteprotocol’ => ‘https’,
‘trusted_proxies’ =>
array (
11 => ‘127.0.0.1’,
12 => ‘::1’,
),

11

You can turn on additional logging to see which login transactions are triggering brute force protection.

The entire chapter was recently expanded on the manual. You may find it helpful:

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/bruteforce_configuration.html

12

Okay i probably got the solution, its very simple as always

I have multiple devices which are connected to nextcloud, i had on my old setup a nextcloud installation on ubuntu. But I used the same dynDNS, the same Users and different accounts for devices for the new nextcloud. But i changed the passwords. I forgot about to connect my new devices to the new proxmox nextcloud. And basically my iphone or ipad is always with me and has the same network, so always there are many wrong login attemps where i am using a browser.

I found the solution in the logs and the mariadb bruteforce attemps folder

thanks for your help! i am sorry for wasting your time

next time i should make a clean reset for all my devices

1 Like