Login throttled until users are locked out

okay · June 19, 2024, 10:26am

Nextcloud version: 28.0.6
PHP version: 8.2

We are facing issues with user login throttled or IPs being completely locked out. Resetting the IP with occ security:bruteforce:reset {IP} helps for the moment. But we do need to solve the issue. We are not aware that there might be some app with a wrong password configured (which was my first guess). And the issue is faced by different users at different places with different IP addresses.

Strange enough, the oc_bruteforce_attempts-table is totally empty. How am I even able to debug the issue in this case?

mritzmann · June 19, 2024, 10:57am

Do you use BasicAuth? If so, that could be the problem.

github.com/nextcloud/server

Brute Force Protection recognizes a successful BasicAuth as a failed login attempt against Nextcloud

opened 09:23AM - 16 Sep 20 UTC

closed 01:13PM - 12 Feb 24 UTC

mritzmann

bug 0. Needs triage

### How to use GitHub * Please use the 👍 [reaction](https://blog.github.com/2…016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to show that you are affected by the same issue. * Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue. * Subscribe to receive notifications on status change and new comments. ### Steps to reproduce For stage environments I use Basic Authentication before Nextcloud so that the installation is not public on the web. This is also useful for new installations. I do not want the Nextcloud Setup Wizard to be publicly available on the web (because this is otherwise a security issue). Therefore I activate Basic Authentication, Install Nextcloud, and deactivate Basic Authentication again. 1. Enable Basic Auth Authentication for your vhost 2. Login with Basic Auth on your url 3. Open Nextcloud Login Page 4. See `nextcloud.log` The successful BasicAuth is automatically detected by the [Brute Force Protection](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/bruteforce_configuration.html) as a failed login attempt against Nextcloud. ### Expected behaviour A successful basic authentication before my login page is not a login attempt to my Nextcloud and should therefore not be considered as a failed login by the build-in brute force protection. ### Actual behaviour Nextcloud recognizes the successful basic auth authentication as a failed Nextcloud login attempt. The operation of a Nextcloud installation behind an additional BasicAuth is therefore not possible without slowing down the user's login attempts. ### Server configuration **Operating system:** Debian 10.5 **Web server:** nginx/1.16.1 **Database:** MariaDB 1:10.3.23-0+deb10u1 **PHP version:** 7.4.10 **Nextcloud version:** 19.0.2 **Updated or fresh install:** Fresh **Where did you install Nextcloud from:** [nextcloud-19.0.3.zip](https://download.nextcloud.com/server/releases/nextcloud-19.0.3.zip) from nextcloud.com **Signing status:** <details> <summary>Signing status</summary> ``` No errors have been found. ``` </details> **List of activated apps:** <details> <summary>App list</summary> ``` Enabled: - accessibility: 1.5.0 - activity: 2.12.0 - admin_audit: 1.9.0 - calendar: 2.0.4 - cloud_federation_api: 1.2.0 - comments: 1.9.0 - contacts: 3.3.0 - contactsinteraction: 1.0.0 - dav: 1.15.0 - external: 3.6.0 - federatedfilesharing: 1.9.0 - federation: 1.9.0 - files: 1.14.0 - files_pdfviewer: 1.8.0 - files_rightclick: 0.16.0 - files_sharing: 1.11.0 - files_trashbin: 1.9.0 - files_versions: 1.12.0 - files_videoplayer: 1.8.0 - firstrunwizard: 2.8.0 - logreader: 2.4.0 - lookup_server_connector: 1.7.0 - mail: 1.4.1 - notes: 3.6.4 - notifications: 2.7.0 - oauth2: 1.7.0 - onlyoffice: 5.0.0 - password_policy: 1.9.1 - photos: 1.1.0 - provisioning_api: 1.9.0 - recommendations: 0.7.0 - serverinfo: 1.9.0 - settings: 1.1.0 - sharebymail: 1.9.0 - spreed: 9.0.3 - systemtags: 1.9.0 - tasks: 0.13.3 - text: 3.0.1 - theming: 1.10.0 - twofactor_backupcodes: 1.8.0 - twofactor_totp: 5.0.0 - viewer: 1.3.0 - workflowengine: 2.1.0 Disabled: - encryption - files_external - nextcloud_announcements - privacy - support - survey_client - updatenotification - user_ldap ``` </details> **Nextcloud configuration:** <details> <summary>Config report</summary> ```json { "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": { "0": "***REMOVED SENSITIVE VALUE***", }, "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "19.0.3.1", "overwrite.cli.url": "http:\/\/localhost", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "memcache.local": "\\OC\\Memcache\\APCu", "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": "6379", "timeout": "0.0" }, "mail_smtpmode": "sendmail", "mail_sendmailmode": "pipe", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "maintenance": false, "loglevel": 2, "theme": "" } } ``` </details> **Are you using external storage:** no **Are you using encryption:** no **Are you using an external user-backend:** no ### Client configuration **Browser:** Google Chrome **Operating system:** Ubuntu 16.04.7 LTS ### Logs #### Web server error log <details> <summary>Web server error log</summary> ``` There is no NGINX oder PHP-Error. ``` </details> #### Nextcloud log (data/nextcloud.log) <details> <summary>Nextcloud log</summary> ``` { "reqId": "YppM8IIViKEhcwHD2FUu", "level": 2, "time": "2020-09-16T08:59:02+00:00", "remoteAddr": "***", "user": "--", "app": "core", "method": "GET", "url": "/", "message": "Login failed: 'mritzmann' (Remote IP: '***')", "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36", "version": "19.0.3.1" } ``` </details> #### Browser log <details> <summary>Browser log</summary> ``` There is no Browser Error, but a slow HTTP Request due Brute Force Protection. ``` </details>

okay · June 19, 2024, 11:41am

No, we don’t use Basic Auth in this installation. We do use a reverse proxy, but the blocked IPs are not the one of the reverse proxy but the ones the individual clients have dialed in with. And we also have a multi-user office with multiple clients and a single, fixed IP address.

The questions that is bugging me: where are the “brute force” IPs stored if not in the oc_bruteforce_attempts-table?

kesselb · June 19, 2024, 11:46am

The questions that is bugging me: where are the “brute force” IPs stored if not in the oc_bruteforce_attempts-table?

If you have Redis configured as memcache.distributed then there.

kesselb · June 19, 2024, 11:50am

Change the loglevel to 1 and look for “Bruteforce attempt from” in your logfile.

jtr · June 19, 2024, 12:18pm

And also entries like:

IP address throttled [...]
IP address blocked [...]

okay · June 19, 2024, 1:06pm

Fair point. Yes, we have redis activated.

okay · June 19, 2024, 1:20pm

Okay, I have now found entries. One user had issues today. She reported that she saw the “throttled”-message. In todays log I do see (all with her legit IP):

a failed login attempt with Firefox 127: “Tried to log in but could not verify
token”
“Logging out”
“Bruteforce attempt from “…” detected for action “login”.”
“IP address throttled because it reached the attempts limit in the last 30 minutes [action: login, delay: 200, ip:…]”

This is the only “Bruteforce attempt”-log-entry for this IP address, though.

okay · June 26, 2024, 7:56am

Our users also use CalDAV-synchronization, most of them with both mobile phone and Desktop PC. And we also use WebDAV-synchronization. May the brute force issues be related to this line-up?