Hi CrowdSecTeam,
i have running the AppSec on a nginx and added to my installation the appsec-crs collection and the crs-exclusion for nextcloud.
Unfortunately there are still connections blocked coming e.g. from the nextcloud agent.
I have attached a screen shot.
The matching rule is 941100 and 941130.
I was not able to find that rules in the exclusion config.
#AppSec CRS out-of-band nextcloud exclusion
1 messages · Page 1 of 1 (latest)
Important Information
Thank you for getting in touch with your support request. To expedite a swift resolution, could you kindly provide the following information? Rest assured, we will respond promptly, and we greatly appreciate your patience. While you wait, please check the links below to see if this issue has been previously addressed. If you have managed to resolve it, please use run the command /resolve or press the green resolve button below.
Log Files
If you possess any log files that you believe could be beneficial, please include them at this time. By default, CrowdSec logs to /var/log/, where you will discover a corresponding log file for each component.
Guide Followed (CrowdSec Official)
If you have diligently followed one of our guides and hit a roadblock, please share the guide with us. This will help us assess if any adjustments are necessary to assist you further.
Screenshots
Please forward any screenshots depicting errors you encounter. Your visuals will provide us with a clear view of the issues you are facing.
we have a pending PR to update the exclusion rules to the latest version, i'd need to check if this FP was fixed or not
Has this been merged? I am also battling appsec related issues with Nextcloud
I also have the crs packages listed above
For me it’s relating to uploading large files
I don't use AppSec but the Nextcloud plugin on ModSecurity works fine for me, did you try following this: https://github.com/coreruleset/nextcloud-rule-exclusions-plugin?tab=readme-ov-file#known-limitations
Maybe open an issue if your still having problems
@delicate plover @viral viper
I just diffed that compared to the crs Nextcloud exclusion on the hub and the files are identical
No, I mean read the instructions in the readme. The plugin has some limitations.
I have modsecurity turned off in npmplus so I wasn’t sure that large file workaround would even do anything
I can definitely try it tho
You can import SecLang rules into Coraza, no need to switch to ModSecurity
sorry to revive this thread, but i stumbled upon the same problem with a slight variation.
for me it only throws out-of-bands when DAVx5 tries to fetch or push calender Updates.
please correct me if i'm wrong but shouldn't calender updates be either whitelisted in "crowdsecurity/nextcloud-whitelist" or "crowdsecurity/crs-exclusion-plugin-nextcloud"?
i don't know how i didn't see that 😅
thanks a lot
It's not included in the readme for the CrowdSec Hub, that's why
Hello, you can use https://app.crowdsec.net/hub/author/crowdsecurity/collections/appsec-crs-exclusion-plugin-nextcloud 🙂
we recently added the support for CRS exclusions rules, forgot to update the thread 🙂
with the collection you don't have to manage the CRS rules directly and it's manage via the hub
well yeah, that collection is in use.
in it's standard configuration it can't parse raw binary data, which makes it unable to read some events which means some exclusions won't work.
it would be nice to have the option to add a single rule to an existing rule collection in a config. don't know if that's already possible.
right now my ruleset from the collection is changed by me, which is a problem if it get's updated
it's this rule btw:
SecRule REQBODY_PROCESSOR "!@rx (?:URLENCODED|MULTIPART|XML|JSON)" \
"id:9508033,\
phase:1,\
pass,\
nolog,\
ctl:requestBodyProcessor=RAW"
yes you can add a single SecRule https://doc.crowdsec.net/docs/next/appsec/rules_syntax#seclang-support unless I misunderstood what you said
it's entirely irrelevant in which specific folder or file the rule is in right?
as long as the file or folder is referenced to be imported to crs?
right now i just added the rule to the nextcloud rule file, which would break if that collection get's an update 😅
didn't have the time to properly read into it to make it non-wanky
yes
can you elaborate on
in it's standard configuration it can't parse raw binary data, which makes it unable to read some events which means some exclusions won't work.
Can you please read here: https://github.com/coreruleset/nextcloud-rule-exclusions-plugin?tab=readme-ov-file#known-limitations
The Nextcloud plugin is facing some engine limitations, so there are some manual configuration that needs to be done. This is missing from the hub at the moment.
It needs some extra configuration beyond just install it, that's why it's not working for @soft hill
Hi all, I've been trying to setup crowdsec appsec with CRS for my nextcloud instance. I've added the nextcloud exclusions plugin, saw the same false positives mentioned in this thread, and found the documentation indicating that the Coraza default body processor needed to be set to RAW instead of URLENCODE for nextcloud instances, but I cannot find the coraza.conf file anywhere.
I'm using Crowdsec in a docker, with nginx as my reverse proxy with the Crowdsec remediation agent installed. Appsec appears to be working perfectly, besides the false positives issue leading to bans
Sorry, forgot to ask my actual question after the context! 😅 Where is the coraza.conf in the Crowdsec Docker to add/edit this rule like the plugin documentation reccomends? Or is there a different persistent way to make this change as a custom config so it won't get overwritten with updates? Thanks for anyone who can help!
@soft hill And to anyone else who stumbles into this issue and looks here, I think I figured out a way to make this work in a way that will survive any collection updates! If you wanted to try as well 😁 I made a custom rule and custom config, then added it to my appsec acquis file
My appsec rule, located in: /etc/crowdsec/appsec-rules/nextcloud_raw_body_processor_override.yaml
seclang_rules:
- SecRule REQBODY_PROCESSOR "!@rx (?:URLENCODED|MULTIPART|XML|JSON)" "id:9508033, phase:1, pass, nolog, ctl:requestBodyProcessor=RAW"```
My appsec config, located in: /etc/crowdsec/appsec-config/nextcloud_raw_body_processor_override.yaml
```name: custom/nextcloud_raw_body_processor_override
default_remediation: ban
outofband_rules:
- custom/nextcloud_raw_body_processor_override```
I'm using the out of band CRS rules, but I'm guessing if you use inband CRS, then you would put this rule under the inband rules instead
and lastly in my acquis.d file for appsec, I put the config for my override above the CRS config, as my understanding is the rule order loading matters, and if there was a coraza.conf wherever it should be, it would be loaded first before anything else. The appsec_configs section of my acquis.d file:
```appsec_configs:
- custom/nextcloud_raw_body_processor_override # Coraza Set Default Body Processor to RAW for nextcloud whitelist
- crowdsecurity/appsec-default # Virtual patching rules (in-band)
- crowdsecurity/crs # OWASP CRS rules (out-of-band)```
If someone has feedback on how this should be done better or if this raises any security issues, please let me know! Thanks 🙏
looks good to me.
rn i'm just wondering how where i should add the config and the rule file.
directly like you did?
in the hub folder in an extra "custom" folder?
in a folder in the appsec-rules and appsec-config folders?
🤔
because a rule override like that should be in my versioning with gitea, but i don't need to add most other configs, since they are just standard and get generated by crowdsec itself
yeah, the direct way is the only way since crowdsec only reads that directory to input the configs and rules 😅
just checking, this config worked for you? 😅
because i can't get it to work like that and i don't know where i made an error
Oh I did a little more learning and reading for a slightly better solution! One second
My notes to me. No custom rule even needed:
"Base Config" has the settings we need, but appsec-default config only applies it to inband rules. We need to add it to out of band as well for it to apply to the CRS rules in out of band mode.
/etc/crowdsec/appsec-config/nextcloud_raw_body_processor_override.yaml
default_remediation: ban
outofband_rules:
- crowdsecurity/base-config```
And my acquis file looks like:
```appsec_configs:
- custom/nextcloud_push_allow # Nextcloud allow push client to work without user agent
- crowdsecurity/appsec-default # Virtual patching rules (in-band)
- custom/nextcloud_raw_body_processor_override # Coraza Set Default Body Processor to RAW for nextcloud whitelist
- crowdsecurity/crs # OWASP CRS rules (out-of-band)```
I'm using docker, and the startup logs acknowledge "custom/" files manually make in the appsec-config directory are local and it will leave them alone. No risk of being overwritten
good to know
what is your custom push allow rule?
It... Is currently broken. I have a thread on that asking for help. 😅 The "crowdsecurity/experimental-no-user-agent" rule keeps alerting because the Nextcloud desktop client does a periodic "GET" to the server without a user agent, if you have the optional notify_push app setup on nextcloud which makes desktop client synching more reactive to changes instead of polling. I tried to use the pre_eval hook to disable that rule specifically for the //push/ws URI it uses, but not successfully
Glad it worked! 😁