False positives with nextcloud notes

I can’t use my nextcloud notes app without triggering the following decision:

“LePresidente/http-generic-403-bf” with my IP.

In general what’s the protocol to manage false positives. Seems like you need to make some kind of whitelist or modification to the rules using yaml files? Any help is appreciated.

Hey we are currently working on a nextcloud whitelists that is currently evolving over time.

https://hub.crowdsec.net/author/crowdsecurity/configurations/nextcloud-whitelist

We need to know what events were poured to the bucket to know how we can add this application to the whitelists. Could you run cscli alerts inspect <id> -d this will output alot of information about each event that poured. You can remove the IP from the output as we do not need this.

1 Like

Cool good to know there is a fix in process. Should I apply the nextcloud-whitelist now or wait?

Unfortunately I accidentally did a ‘cscli decisions delete -all’ or something to that effect when desperately trying to get my services back up. However, I have daily appdata backups of my docker containers… is this something I can pull directly from the docker appdata?

Hi,
I stumbled over this discussion and it helped my debugging my nextcloud-bulk-upload problem with crowdsec.
The alert looks like this:

- Date: 2025-03-16 18:40:16 +0000 UTC
+-----------------+--------------------------------------------------------------+
|       Key       |                             Value                            |
+-----------------+--------------------------------------------------------------+
| ASNNumber       | myASN                                                        |
| ASNOrg          | myASN                                             |
| IsInEU          | true                                                         |
| IsoCode         | DE                                                           |
| SourceRange     | 84.XXX.XX.0/20                                               |
| datasource_path | /var/log/traefik/access.log                                  |
| datasource_type | file                                                         |
| http_args_len   | 0                                                            |
| http_path       | /remote.php/dav/files/7b90fa0a-2f08-4ebe-9d66-cd3f0d7a1374/myMagicFileName  |
| http_status     | 404                                                          |
| http_user_agent | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0)      |
|                 | Gecko/20100101 Firefox/136.0                                 |
| http_verb       | PROPFIND                                                     |
| log_type        | http_access-log                                              |
| service         | http                                                         |
| source_ip       | mySourceIp                                                |
| timestamp       | 2025-03-16T18:40:16Z                                         |
+-----------------+--------------------------------------------------------------+

And the point is, that the nextcloud is going for the URL /remote.php/dav/ which is not whitelisted by the nextcloud-whitelist-parser.

I fixed it by manually adding this line to the whitelist:

- evt.Meta.http_status in ['404', '200'] && evt.Meta.http_verb in ['PROPFIND', 'GET'] && evt.Meta.http_path matches '^/remote.php/dav/'

As remote.php is also used for other use-cases in nextcloud, this could also lead to problems while using the Notes app.

Cheers

1 Like

Looks like Nextcloud also triggers http-probing when searching for .noindex, .nomedia, and .nomemories files on federated servers.

I guess something like this sould do the fix:

- evt.Meta.http_status == '404' && evt.Meta.http_verb == 'PROPFIND' && evt.Parsed.file_dir startsWith '/public.php/webdav/' && lower(evt.Parsed.file_name) in ['.noindex', '.nomedia', '.nomemories']
1 Like

I want to share few more findings I had to add in my installation to prevent false positives in my Nextcloud instance

name: _my/nextcloud-whitelist
description: "Whitelist more events from Nextcloud"
filter: "evt.Meta.service == 'http' && evt.Meta.log_type in ['http_access-log', 'http_error-log']"
whitelist:
 reason: "my Nextcloud Whitelist"
 expression:
  - evt.Meta.http_status == '404' && evt.Meta.http_verb == 'POST' && evt.Meta.http_path == '/login/v2/poll' #device login
  - evt.Meta.http_status == '404' && evt.Meta.http_verb == 'GET' && evt.Meta.http_path == '/push/ws' #notify_push not running
  - evt.Meta.http_status == '404' && evt.Meta.http_verb == 'GET' && evt.Meta.http_path contains '/remote.php/dav/addressbooks/users/' && evt.Parsed.http_args contains 'photo' #addressbook
  - evt.Meta.http_status == '404' && evt.Meta.http_verb == 'HEAD' && evt.Meta.http_path contains '/remote.php/dav/files/' #HEAD while instant upload
  - evt.Meta.http_status == '404' && evt.Meta.http_verb == 'GET' && evt.Meta.http_path contains '/contacts/css/contacts-index.css' && evt.Parsed.http_args contains 'v'
  - evt.Meta.http_status == '404' && evt.Meta.http_verb == 'HEAD' && evt.Meta.http_path contains '/ocs/v2.php/apps/spreed/api/v1/(chat|room)' #Talk chats

from my experience Nextcloud is doing good job redirecting unauthenticated requests to login page so likely it’s safe to whitelist all 404..